[COLOR] Slight colour-shift in Viewer and exported footage.

[StudioPetrikas]

Commit Hash 10bc448c

Platform Windows 11 & macOS 12.1

Summary Slight issue with colour in the viewport (and the output) It appears that there's a slight problem with the green channel. When I load footage into Olive, and pixel-sample the neutral values, it appears that the green channel does not match the red and blue channels. This results in a pink-ish tint, that is most noticeable on the neutral grays (like the neutral gray UI in the attached files).

Additional Information / Output I have tried different OCIO configs. My main OCIO config that I also use in Blender produces expected results in Blender, but unexpected results in Olive.

I can also replicate this issue on a macOS machine.

Footage for experimenting: https://user-images.githubusercontent.com/70055734/183100364-986bb518-9428-4da6-94fc-52a2c53a7b69.mov

Color-picker values on an achromatic (neutral) surface. Notice how R and B channels are identical, while G is slightly off.

This is also prominent in the export. After exporting, if the exported footage gets imported back into Olive, it results in a futher shift (another layer of "pink")

While it's not an incredibly important issue, as the discrepancy is tiny, and not noticeable with colours, it is noticable with neutrals.

My current fix is to adjust the green channel with the OCIO Colour Grading module.

[ThomasWilshaw]

Hmm, I also notice that the alpha value is ever so slightly off in your screen grab. What colour space are you importing as?

[StudioPetrikas]

Forgot to mention that, sorry.

Footage set to sRGB, same as the Display setting. On a mac, footage set to sRGB, Display set to Display P3.

[StudioPetrikas]

Slightly more information: Tried screen-recording with a variety of different settings, GPU/CPU, colour formats, file formats and 2 different recording software. Result is the same.

However, if I choose to save a .JPG from within the same software, the reported issue disappears.

Maybe this information is useful.

[p9malino26]

Think this is due to output colours being different after export due to compression algorithms. I noticed that changing the compression parameters and then exporting gave different results.

[StudioPetrikas]

Think this is due to output colours being different after export due to compression algorithms. I noticed that changing the compression parameters and then exporting gave different results.

How would export/compression settings affect the Viewport/viewer?

[ThomasWilshaw]

I've had another look into this and possibly found the reason it's happening. I tried a different test target (Belle Nuit) that was stored as tiffand had no issues with neutral colours. I then inspected your test clip in MediaInfo and saw it is tagged as BT601, not BT709. So I suspect what is happeneing here is that Olive is using the wrong conversion matrix. We're using a custom YCbCr GPU shader and that only supports BT709 (I think...)

[ThomasWilshaw]

Okay that's not the case as our decoder is correctly picking up the colour space tags so I wonder if the video is just incorrectly tagged?

[StudioPetrikas]

That is incredibly weird. To my knowledge, the only way to tag a video was through NCLC tags?

I did test it with random camera footage and it looked like there was enough difference for me to assume that it's not just this clip.

I wonder why other software, in this case, Blender, using the same OCIO config would display that same file correctly (well, who knows what's "correctly" at this point)

[EDIT]: I think you're correct. Redoing tests.

[StudioPetrikas]

Okay, so I downloaded MediaInfo, this clip I've done just now returns correct colour space tag (even though I've changed no settings, weird)

However, the same shift is still there. https://user-images.githubusercontent.com/70055734/195144643-a6f1760d-34de-40dd-b425-ad402b3a8e5d.mov

I'm now thinking that's a me-problem, but I would really love to get to the bottom of this.

[ThomasWilshaw]

I don't think it's a you problem as I'm getting the same results that you are, none of the neutrals are neutral in Olive but they are if I open in VLC, which implies there's something off with out decoding. Are you able to provide any of the sample images you're using (like the Macbeth chart?).

If I set the input space of the video as linear the neutrals are still off so either it's happening when you encode it or it's happening when Olive decodes

[StudioPetrikas]

Of course https://github.com/sobotka/Testing_Imagery/blob/main/CC24_BT-709_linear_1931.exr

Let me know how I can be useful.

[ThomasWilshaw]

Ah it's @sobotka's set, I should have spotted that, I wonder if he has any insights here?

[sobotka]

If it shifts by more than an eight bit code value due to rounding, I’d wager on the YCbCr to RGB trip and round trip.

[ThomasWilshaw]

I've just opened the original EXR and the neutrals there also appear to be off

[ThomasWilshaw]

Some of the other synthetic charts on there are better but not perfect

[StudioPetrikas]

I've created this issue, because I noticed the issue on the interface of the software in that clip. "Darktable's" UI should be perfectly neutral - and it is - just not in the recording when loaded into Olive. I didn't intend to put too much focus on the chart itself.

Worth repeating that if I load up a JPG into Olive, there's no shift; it's as neutral as it should be. Static images may behave differently.

[ThomasWilshaw]

Yes I appreciate that, I just notice that the colour picker in darktable is reading that grey patch as neutral but Olive isn't

[StudioPetrikas]

Quite a bit of rounding there in the Darktable's picker. Loaded into blender, and if you round to a thousandth decimal, that patch comes out neutral, even though it isn't perfectly neutral.

Same in Olive, neutral if rounded to .001 (sRGB output)

I wouldn't read into it too much. I think any solid gray patch would work for testing. Do you want me to make a test image of something?

[ThomasWilshaw]

I've tried opening this in various other media players (Blender, DJV, Resolve) and they all read the UI and all but the brightest patch as being properly neutral, which heavily implies Olive's decoder is doing something wrong (or everyone else is but that would seem unlikely).

I need to try openeing the clip in Olive via the fall back CPU decoder to see if that decodes correctly but it appears to be broken atm so we'll have to sort that first.

[itsmattkc]

I'm fairly positive the issue is that we don't have a LUT for SMPTE 170M. Olive is almost certainly defaulting to a Rec.709 LUT because we don't have anything more suitable yet. I asked @ThomasWilshaw to create one when this issue was first posted, but I think he forgot, and to be fair I never posted in this issue that that was a likely cause.

[ThomasWilshaw]

Just a quick update on this, some recent commits fix this issue on Mac and Linux but we're still having issues on Windows. A workaround is to set the sequence preview resolution to full and you should get the correct results.

[StudioPetrikas]

Can confirm, looks good at full resolution and looks good in the exported footage! Thank you so much for your time, I'm very happy with the result.

[sobotka]

@ThomasWilshaw Can you summarize what is going sideways? Related to sampling resolution?

[ThomasWilshaw]

It's actually a combination of things that have caused this. The first issue was in the yu2rgb shader, when we were transforming the uv components from the stored range of 0-1 to the used range of -0.5 -> + 0.5 we were subtracting 0.5. Most files are stored as int, say in the range 0-255, so the neutral code vaule for the uv components is 128/255, not 0.5. Fixing this solved the issue on Mac and Linux and Windows at full resolution, but for some reason AVFilter on Windows (which we use to resize the yuv data to match the sequence resolution before sending it to be decoded on the GPU and to handle deinterlacing) is messing up the code values. A potential solution is to stop using AVFilter as we can do the de-interalcing on the GPU and to use sw_scale on it's own which was working in the past.

[itsmattkc]

This should be more or less resolved by now.