mltframework
Text overlay shifts levels slightly
Shotcut 24.01.28 The fading out of the title in the attached sample makes the luma shift by 1 or 2 steps down, see the waveform monitor. Or better: the addition of the title shifts the luma 1 or 2 steps up. Changing opacity and/or the RGB value of the text (254,254,254) doesn't have an effect. Am I missing something? The text is added on a separate video track.
Edit: It looks like the appearance/disappearance of the text would trigger a change between limited range<->full range. (The video is limited range).
https://github.com/mltframework/shotcut/assets/55814862/cea26974-b344-4d19-b7d5-865ac3af93a2
I have not reproduced this. I am using version 24.09. I place a limited color range video on V1. I added Speed: Forward Only with keyframes set to 0 speed in order to have a still frame to be able to more easily compare before and after a text clip on V2. The Video Zoom scope is locked onto the same pixel outside of the text filter.
Before
After
Selecting a pixel within the region of the Text: Simple filter does not make a difference. I also did an export and compared the frame before the text and the first frame with text.
Thanks for taking a look. Interesting, I can reproduce your test. I did similar with 2 clips as per the attached file: The first clip is rock stable (as in your test), but the second clip gets the shift when the text appears, and reverts back to the former colors when the text disappears. Strange...... Clip 1 is a .png source. Clip 2 is .mp4 source, colorspace BT.709. Shotcut video mode is SD PAL. Edit: It seems the colors are correct when the text is ON ..... (tested with various colorbars, for 601 and 709 ....). Anyway, the differences are subtle (2...4 steps in 8bit RGB), but the Text on track 2 seems to trigger something when the track 1 video is 709 colorspace ...... I understand that there can be minor losses (e.g. by rounding) when converting 709<->601 and YUV<->RGB, just wondering why the appearance of the Text on track 2 has an influence on the colors of the video on track 1.
https://github.com/user-attachments/assets/6f61b051-778d-4071-af4e-0bf58c490cc7
Update: After some more experimenting I think I found the culprit: The color shift caused by the text overlay happens when the video is not strictly limited range YUV, but has Y excursions in the 0...15 and/or 236....255 range (superblacks and superwhites, or out of gamut colors.) Attached a clip for demo. While the RGB values may stay intact even for the out-of gamut case (2nd half of the attached clip), the appearance of the text impacts the YUV. The text overlay somehow "legalizes" or clips the YUV. On PC one might not see the difference, on TV (using the studio matrix for YUV->RGB conversion) one can see the color shift. Does this make sense?
https://github.com/user-attachments/assets/bb7f1191-5dc8-41c7-978e-ab9d46e42c31
That makes sense because these effects are done using 8-bit integer RGBA, which is in full range. When converting limited color range YUV to full range integer RGB, it will truncate. You must override the YUV clip to full color range to preserve it.
This is not something that will be fixed as it is basically requires a massive rewrite including possibly libraries we do not control, or adding functions to adjust RGB from and to sRGB (sRGB is always full range and many media assets use that). That’s not going to happen.
This problem might not occur with GPU Effects, however, because it operates in 16-bit floating point RGBA, which can accommodate the excursions. But I would need to check what it does when converting back to YUV.