Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text overlay shifts levels slightly #1517

Closed
Sharc99 opened this issue Feb 18, 2024 · 4 comments
Closed

Text overlay shifts levels slightly #1517

Sharc99 opened this issue Feb 18, 2024 · 4 comments

Comments

@Sharc99
Copy link

Sharc99 commented Feb 18, 2024

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).

Level.shift.mp4
@ddennedy
Copy link
Member

ddennedy commented Oct 8, 2024

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
image

After
image

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.

@Sharc99
Copy link
Author

Sharc99 commented Oct 9, 2024

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.

Shotcut.shift.mp4

@Sharc99
Copy link
Author

Sharc99 commented Nov 28, 2024

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?

Out_of_gamut_for.Shotcut.report.mp4

@ddennedy
Copy link
Member

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.

@ddennedy ddennedy closed this as not planned Won't fix, can't repro, duplicate, stale Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants