I just viewed the same image (standard NTSC color bar test) side by side on my Surface Pro in Firefox and Google chrome and the colours in Firefox are slightly more washed out than in Chrome - they are definitely not identical.
Oh, man. The video I was showing you was already edited and I deleted the project already. I only have the final video, aka the one you guys have been seeing!!
So I did a quick test.
This is Shotcut Player, with VLC running on top of it.
With both videos running. near-perfect audio sync, the differences in color were very apparent.
This screenshot was taken with both players paused; I didn’t want to catch one of them between frames.
I can see a distinct skin tone difference on my forehead.
Same final video.
What version of Shotcut was that? If it’s the latest, does the previous version do it too?
21.03.21
I’ll try to run some of my appimages later this evening.
AppImages are awesome. Thanks for testing. I’m not near a computer or I would do it myself. There was a long stretch of time that Shotcut color accuracy was rock solid, so this is interesting. When I get back, I’d like to run color bars for expected values.
It is all about context. That was questioned, improved, and verified for export. She says the export is fine. This is about preview. The bug is accepted. It is probably incorrect coefficients in glwidget.cpp.
My 21.01 is gone, and it made little sense to run it against 2102beta.
So I ran it against my older appimages (Not exactly apples-to-apples; 18.11.18 never would support my external monitor.)
Shotcut 18.11.18 vs VLC
Shotcut 18.11.18 vs VLC
Shotcut 20.11.28 vs VLC
Shotcut 20.11.28 vs VLC
Shotcut 21.03.21 vs VLC
Shotcut 21.03.21 vs VLC
Judge for yourselves; I think that VLC is not as good as Shotcut.
It’s not a question of which is good vs the other unfortunately. It’s a question of which is correct.
Does anyone have the SMPTE 170M to XYZ Matrices? It should be relatively easy to model the hue/saturation shift to see if that is the problem.
This should be fixed for the next version 21.04. I verified the problem and fix by using color bars rendered in Y’CbCr and an color eyedropper program to compare Shotcut with ffplay and VLC. I immediately saw a difference in numeric color values between the two, with ffplay and VLC being identical. These color values are very close to their mathematical ideal values.
Ideal 8-bit integer:
color | RGB |
---|---|
yellow | #BFBF00 |
cyan | #00BFBF |
green | #00BF00 |
magenta | #BF00BF |
red | #BF0000 |
blue | #0000BF |
ffplay/VLC (after conversions RGB source -> 8-bit Y’CbCr -> RGB OpenGL display, some imperfections are expected due to rounding and quantization):
color | RGB | delta |
---|---|---|
yellow | #BFBF00 | 0 0 0 |
cyan | #00BFBE | 0 0 -1 |
green | #00BF00 | 0 0 0 |
magenta | #BF00C0 | 0 0 +1 |
red | #BF0001 | 0 0 +1 |
blue | #0000BF | 0 0 0 |
Shotcut-current:
color | RGB | delta |
---|---|---|
yellow | #C0BE01 | +1 -1 +1 |
cyan | #01BFBF | +1 0 0 |
green | #01BE00 | +1 -1 0 |
magenta | #C000C1 | +1 0 +2 |
red | #C00002 | +1 0 +2 |
blue | #0100C1 | +1 0 +2 |
Upon reviewing some coefficients and the math to derive them, I found something suspicious and made a small change. After testing the change, Shotcut’s values match those of ffplay and VLC.
I don’t know if I understand what this implies. I think this will imply an incorrect reference in color correction.
So if I am working on a color correction based on the Shotcut previewer, maybe all the adjustment work is not correct.
Is this so?
In case the answer to the question is yes,( and since I don’t know if I will know how to do the comparative tests - I intend to do this today).
does anyone know if the previous version or another one does not have this behavior?