@topazlabs-9702 From your screenshot, your colorshift seems to match the following description… BT.601 vs BT.709…
Generally speaking…
- Red too orange, green too dark? 601 is being decoded as 709.
- Red too dark, green too yellowish? 709 is being decoded as 601.
Your original SD is likely being converted from Untagged or BT.601 (SD) through to RGB48le and then to BT.709 (HD). You may need to add a colorspace conversion filter into the chain or override the colorspace, colorprimaries and colortrc of the input - any unfortunately this is not exposed in the GUI.
Video Players are not blameless either. Sometimes players will assume one of:
- A) all content is BT.709
- B) SD content is BT.601 and HD content is BT.709, making an assumption based on the resolution
- C) all content is BT.601
Try a color-aware player such as MPV and see if you get a different result. Not all players are equal when it comes to correct colorspace rendering. A player should be using the colorspace and transfer characteristics info to convert back to RGB - and often enough, many players make incorrect decisions, even when fed with correctly-tagged content.
The above-linked article it seems to describe your issue…
On the original H264 encode, you’ll see the red is a bit more dim. A bit more orange. This is the telltale sign of 601 vs. 709 gone wild — reds becoming orange. The encoder used the 601 (SD) coefficients, but then the decoder uses the 709 (HD) ones because it auto-detects a video above 720 pixels in resolution.
To add further complication for anime, you may have an original which uses NTSC-J / System-J colorspace/primaries/transfercharacteristics rather than BT.601.
I do agree that TVAI needs better colorspace override and handling to ensure a clean conversion from somethink like BT.601 YUV to RGB48le and then to BT.709 or 2020.
Much of confusing color and range handling is inherited from the underlying FFmpeg, and may not be Topaz’s original fault, but since TVAI is a wrapper for FFmpeg there needs to be a way to control the colorspace / primaries and transfer characteristics through the GUI, rather than let the codec and decoders and players randomly guess the color characteristics. The moment that Topaz chose to operate in the RGB48 pixel format within the tvai_up filter, the burden of responsibility for accurate pixel format, colorspace, color primaries, color transfer characteristics and chroma sample location conversion back to YUV then falls on Topaz’ shoulders.
I believe that TVAI should:
- provide documentation that describes end-to-end colorspace workflows from common use cases such as RGB images, YUV SD video, YUV HD video etc. With reference to pixel format, range, space, primaries, transfer characteristics and sub-sample chroma location
- provide public sample test patterns (perfect source and TVAI sample output) on the documentation site which has been tested in a color-calibrated environment. This allows users to ensure that it isn’t a player or viewing device that is making poor assumptions on playback.
- Allow the override of the input tags (range, space, primaries, trc, chroma_loc) in the TVAI UI - especially if any of the color characteristics are Unknown [2}. An “Auto” could still make a best guess based upon Resolution/Framerate
- Ensure perfect internal conversion to rgb48le pixel format, even before tvai_up starts messin’.
- Allow the user to select a target/output color model that matches one of the industry standard templates defined by [ BT.601 | 709 | 2020 | 2100 | sRGB ] standards.
- Ensure that the colorspace, primaries, transfer and range is actually converted, not just re-tagged.
- Resampling from RGB48-FullRange to something like YUV 8-bit LimitedRange is never going to be mathematically perfect, but if the previous steps are taken then the inherent inaccuracy in pixel-format resampling and encoding quantization can be minimized.
