Originally Posted by D-Nice
Is there proof it is not actually happening at the decoding level? There is proof that digital displays are not properly decoding 709 and 601. Not trying to be combative here. I just want to understand your position.
I don't have solid proof. But here is an example:
If I measure the primary color gradients at 8 points on a Samsung D550 (EU) when it's set to Native
color space settings (Of course, this is just a "preset" like the others. I do know it has some non-zero/non-peak values stored in the main-borad software. I can even modify them if I wish to build a new custom color space for myself and it will be still labelled as Native
...) and I draw a chart from the chromaticity then I get a straight constant line.
If I measure the same eight points with the Auto
color space settings then I get a seemingly-exponential curve (It was hard to believe when I saw this at the first time but it's repeatable and makes sense if I examine movie contents with over-saturated dark and under-saturated bright skin tones after a calibration with 75% stimulus patterns).
This let me think that the problem is the CMS code which incorrectly mixes the emulated colors from the native primaries.
And the same thing happens if I go to the service menu and I unlock the Custom
color space (just like when I fire up a serial console to re-adjust either the Auto
or the Native
presets from the top debug menu).
If the gamut mapping is correct then I think I should see constant chromaticity across the points of the color gradients, no matter what color space settings I use (the actual values may change but remain equal between the stimulus levels - but it's not the case...).
If it's only the color decoding to blame then I guess I should see similarly incorrect behaviors with all color space settings (including a factory default Native
But what I see is that the Native
color space looks consistent (the chromaticity is constant across the whole gradient) and the emulated gamuts (no matter if it's a factory preset or a custom calibration) are obviously wrong.
But, of course, this does not necessarily mean there is no problem on the decoding side (may be it's just hard to see when masked by other factors - for example, if the Native
is set to be very saturated than it clips a curve to a straight line as you can't get further than your native primaries. So the decoding step can theoretically produce a curve which would exceed the native gamut and the CMS can clip this back to the borders, leaving you with a constant chromaticity. This is -while seems less probable to me- looks theoretically possible.).
You are right. We can never be sure if we see the true primaries.
Especially not with the Panasonics. On their 2011 TVs, the primaries also move if I make a huge adjustment with the white point controls (for example, R,G,B-DRV=FF,FF,FF gives me a very narrow gamut, even though this should produce a state closer to the "native" panel characteristics).
By the way, I usually push the color controls to their upper limit in the user menu or use the built-in test pattern generators in the service menus when I profile my colorimeter.
I measure R,G,B only and I keep the white for the validation of the colorimeter correction matrix.
I don't say this gives you the highest possible saturation but I think it should because the marketing guys could always kill for even more colorful displays, so a "shop mode" (which is not magic, just another preset...) should be able to achieve full saturation. (Or the poor software engineer may never sleep well at night but dream with mad marketing guys.
About the original Panasonic color issues...
Does that one happen with every panel brightness settings?
Our EU models do not have that control and I guess the ~25fl peak brightness equals with the peak brightness of the Low setting in the US.
And I see no obvious problem with the colors.
In that case (I am only assuming it's linked with the Panel Brightness) how the Panel Brightness setting may affect the color decoding
Shouldn't that control make it's work well after the decoding step (at the end of the chain, as it's a panel driver setting)?