Red too orange, green too dark? 601 is most likely being treated as 709 somewhere in the chain.
In order to help the topaz team, would you post the underlying FFmpeg command? And ideally the logs?
Please share which media player you are using. Media players can make incorrect assumptions at playtime. Not all players are color correct. It may be worth trying a few players (Quicktime, FFplay, MVP, VLC) to see if you get differences between players. Assuming you are on a mac (given that you are using a lot of Apple codecs), Quicktime Player would be the reference player.
I assume that your end goal is upscaling to one of the HD standards, and thus by implication your colorspace should be converted to (and tagged as) BT.709 colorspace? If you are enhancing the SD without upscale, you most likely want to keep BT.601. If converting to HD then you want to end up with BT.709. And if going to 4k that gets a little complex.
A common problem… If you are converting to HD, but the content remains BT.601, that is where players make assumptions based on the resolution. The player assumes BT.709 (because of the resolution), but the content is BT.601… and that’s where a red>orange shift can come in.
You can check the tagging of any file (source, output) at both frame and container level with:
$ ffprobe -loglevel 'level+error' INPUTFILE -read_intervals '%+#1' -show_entries "frame=color_range,color_space,color_primaries,color_transfer,chroma_location : stream=color_range,color_space,color_primaries,color_transfer,chroma_location" -print_format 'json'
There’s a thread where one user has asked that any issues with color-shift are centralized. Urgent: Topaz Video AI's Unwanted Color & Contrast Shifts—Vote to Fix & Share Your Findings! - #12 by a-cli-user. [The thread name from OP is somewhat sensationalist (“URGENT”), but the request in the thread comes from a good place.] Feel free to add your findings or link your bug report for others. It is an interesting observation that the particular codec choice has an effect on color-shift, especially your observation around FFV1 10/12 vs 8bit. That is a useful observation.
TVAI operates in RGB rather than YUV, which is a little odd. Video files typically start as YUV pixel format. TVAI then converts those internally to RBG48le, and then during the final encode, they typically end up back as YUV pixel format. Within that process the colorspace/primaries/trc can sometimes get lost. And because of the complexities of upsampling and then downsampling 8bit, as well as limited vs full range, it is not mathematically perfect.
Test cases always help. Here’s a useful FFmpeg command that you and Topaz Support can use to create synthetically generated, correctly-tagged PAL-SD BT.601-625/PAL source to throw into Topaz to test the colorshift from PAL-SD. This command ensures that the frames in the test case are tagged correctly at frame level, as well as container level.
$ ffmpeg -f 'lavfi' -color_range:v 'tv' -colorspace:v 'bt470bg' -color_primaries:v 'bt470bg' -color_trc:v 'smpte170m' -i "pal75bars=size='pal':rate='pal',setdar=ratio='(4/3)',format=pix_fmts='yuv420p',setparams=range='tv':colorspace='bt470bg':color_primaries='bt470bg':color_trc='smpte170m',trim=end_frame=300" -codec:v 'libx264' -color_range:v 'tv' -colorspace:v 'bt470bg' -color_primaries:v 'bt470bg' -color_trc:v 'smpte170m' "palcolorbars.mp4"
Best of luck. Color conversion can be tricky in the underlying FFmpeg, even before TVAI starts messing with it.
