I’m thought I read about actually losless video codecs but I can’t remember the name of one (though you could output and select “uncompressed” which should give a lossless video output). But .TIFF or .PNG would be actual lossless image codes you could encode to.
If an app didn’t change anything in the pixel values (eg. you only used cuts or you just re-encoded but added audio) and encoded to a true lossless codec then you wouldn’t lose a generation (you wouldn’t lose any picture quality at all as long as the app stored the pixel values correctly and didn’t convert them in a way that there’d be some rounding error or other difference when re-encoding.
So .png and .tiff are true lossless codecs.
ProRes is visually lossless but not true lossless (there may be times when having a true lossless video codec would help. Like I said it might help a bit with keying. If you want to adjust the colours/brightness a lot after encoding then having true lossless might help a bit there (since even if it was visually lossless if you compared both straight after encoding it might be affecting parts of the picture that you might want if you wanted to adjust the colours a lot later).
But you’re probably in that most of the time ProRes (eg. 4444) is probably good enough for a high quality codec.
If I compared the rgb values of a .png file with the source png (assuming I haven’t edited any pixels in it) it should be identical (again assuming the app doesn’t do anything that affects the pixel values causing it not to be the same) - so lossless. If I compared the rgb values of a prores encoded video to the source video it may not be identical - so not lossless (but visually lossless).
Huffyuv and lagarith are compressed losslessly if you retain the same colour space. Uncompressed (raw) video is too but file sizes are horrendous. Noone of these are available in TVAI, not from within the normal user interface anyway.
Running out of memory seems to be caused by selecting too many filters simultaneously. So, if I limit filter selection to one or two per run, VAI should be able to handle it with no issue.
I’d like VAI to accept any and all filters being selected but tell me that it will take X times longer because it will have to do several runs to accomplish what I’m asking. That would save me from having to set up each run manually.
Great effort from you guys, especially for the “face recovery”. I’m really looking forward to it.
One thing I really wish Topaz can have is the “brightness” enhancing for video which is too dark, or in low light environment. We really want a detail recovery in that area. Thank you.
Hello, I encoded a video clip that lasts 3 minutes from 1080p to 4k in pro res and it began to weigh 42 GB. There is some kind of optimization? Like a lot for a three-minute video)
The ProRes codecs use a high bitrate. If you used the ProRes 422 HQ codec and still want ProRes but want a lower bitrate you could choose the ProRes 422 LT codec.
If you don’t need it to be ProRes then if you choose one of the other codecs (eg. H264…) then that will allow you to specify the bitrate you want to use.
ProRes codecs are only if you want the highest quality (eg. for intermediates).
Prores lt seems to be what I used. Very noticeable difference for the better. Thank you for such a breakthrough, this version transforms the video very well, I wish you success in improving it even more
Okay. I was just just saying that if the amount of disc space used was more than you wanted then you could use the other codecs instead if you didn’t need it to be ProRes, and the LT ProRes version should use less bitrate than the HQ ProRes one (but not quite as good quality).
I’m just a user though, not one of the developers of this.
Altogether Topaz Labs 3 seems to have improved quite significantly with the updates since the release of the original V3. I am now very happy with the results, yet there is something I really miss which is the possibility of exporting files as MXF beside MOV.
MOV are perfect if you work with a Mac, with a PC you can still work with MOV but MXF would be much better suited.
I hope you will bring this featuren keep up the good work !
true but its is more convenient to have a aio program if you know what i mean lol. i use qtgmc for deinterlacing (or staxrip) handbrake is kinda meh for de interlacing unless i need it done quickly using yadif.
Does the roadmap still include eventually moving to GPU encoding?
I still have yet to move beyond 2.3 as I do a lot of batch work and the batch processing was broken on every update after that. Admittedly my license is now lapsed, and I do not see any of the new features giving many features as a “must” for updating. None of the 2.6.* builds even worked for me.
The only improvements in speed I can honestly see happening will be moving the encoding pipeline process on export from the CPU to GPU encoding. This was promised as a coming feature way back in development, and has sort of been quietly dropped as far as i can tell.
