Input colorspace settings not working properly with some output codecs

[Tom131 (Tom)]

1. The bug / behavior you have encountered
   (Before you ask, yes, I have the input color formats set properly.)
   Try any of these output codecs with SD PAL video (don’t know about NTSC), and you’ll get color shift. Other codecs convert colors fine. I can notice color shift in either viewing mode, or when the file is exported playing in a media player. Here are the codecs that don’t work right:
   ProRes - all profiles.
   FFV1 (ONLY 10/12 bit modes, 8bit is fine)
   QuickTime V210
   QuickTime R210
   QuickTime Animation

2. Any screenshots as necessary
   Top image: original colors / Bottom image: wrong colors (red shifts to orange for example).
   
   

[kyle.topazlabs]

Can you share a sample of the video you are using as an input and what the correct color profile is and what you are setting it to in the input settings?

This way we can try and replicate the issue and see what is going on. Logs will also help.
In order to troubleshoot this, I will need your logs and your full system profile.

To gather logs, please select Help > Logging > Get Logs for Support and attach the zip file to your reply.

[Tom131 (Tom)]

Sent in a message.

[a-cli-user]

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.