I’m not 100% how all of this stuff works, but there shouldn’t be this much color shift (open both in new tab and switch between them to see the problem). I’m convinced this is because topaz doesn’t read the color primaries/matrix settings. You can set them in MKVToolNix, but Topaz probably doesn’t read them - for more info google: “mkvmerge – Merge multimedia streams into a Matroska file”, open and do- ctrl+f: “–color-primaries”.
Even youtube has the same issue where if you don’t put the right settings, the colors will get shifted, even when uploading 720x576 video which should always be assumed as BT.470BG.
ITU-R BT.709 =/= ITU-R BT.470BG =/= SMPTE 170M ==== (HD colors =/= SD PAL colors =/= SD NTSC colors) .
Hybrid (selur DE) also had a similar problem, and I never understood what was going on, until me or someone else (can’t remember) made Selur realize that you have to set the correct matrixes and stuff for SD videos, unless you want color shifting (so the program needed an update to assume stuff better). I think the program was always assuming NTSC colors or something like that.
Please fix, this has been a problem for a long time on this software.
edit: Jesus, just look at this. How has nobody noticed this, not a single developer???
I cannot find any meaningful color shifts in your first set of examples. The grain in the first image makes it darker over all, but the colors in the second image look like the correct shades minus the dark grain.
There have been several reports of color shifts over the years. Some are from incorrect colorspace conversions, but others are proven to be unique to specific AI models.
Personally, I use the CLI to correct the colorspace conversion when TVAI doesn’t get it right. All processing in TVAI is done in RGB48le. Usually the trick has to do with converting from that, to whatever you need the final colorspace to be. (ffmpeg is pretty good about converting most colorspaces to RGB48le correctly and automatically.)
Comparing this to all the other reports about color shifts, this one is lacking critical details. What model was used… Source detail… Output details…
Sorry. This is my convoluted way of answering that: they know, but it’s also a much more complex mess than most people fathom. That mess is not unique to Topaz, but all digital videos.
It wouldn’t be a mess if they even added an option to select which color space you want to convert from. Just a manual option, or at least assume the cs correctly. Now I’ll have to add another lengthy step to this already long process, great.
What model was used? Doesn’t matter, happens on all of them.
There is a clear difference. I told you needed to flip between the images.
No. It’s still a mess. The fact that more than one colorspace exists is a mess. Letting people override what the input colorsapce is, is just one way to possibly account for some videos. But there will always be videos where that doesn’t help. Take animated gifs for example. They are only allowed 256 different colors. A custom pallet (colorspace) has to be made for each new gif…
Sorry, sometimes I choose the wrong wording. I meant it wouldn’t be a mess when instead of letting a program decide everything for you and making a mess of dealing with other softwares to convert to proper colorspaces and whatnot, you’d adapt and learn to properly set everything yourself.
And for the GIF conversions, it’s not important, as those colors are probably not accurate anyway.
I’m assuming most people convert SD footage with either ITU-R BT.470BG or SMPTE 170M color primaries (or whichever NTSC/PAL uses), so the program must’ve been optimized for these two in the first place!
If Hybrid fixed this similar problem, then Topaz can do it too.
