8:28 p.m.
On Feb 20, 2008, at 5:25 AM, Florian Höch wrote:
RGB values no. Equivalent LAB values yes.
You are changing the LAB values of each pixel *darker*. That means
there are numerous pixels that were simply out of gamut for CMYK with
ECI-RGBv1 that have been made darker and are now in gamut for CMYK.
While you have the same gamut volume, you have shifted the location
of those colors within that color space by changing the TRC.
Have you tried this test with ECI-RGB primaries and a TRC set to
gamma 2.4? 2.5? 2.6? 2.7? What were the results using the same
technique? What is the explanation for the results?
1.
You don't even know the *relevance* of the numbers you've collected
in terms of human vision because those CMYK values haven't been
turned into LAB colors and compared for redundancy within a certain
delta E00 value. You may have higher numbers with the L* space, but
you may have substantially high redundancy as well. Since it's not
tested, it is not known.
2.
It is disputable as to how many colors humans can even distinguish.
You will get a different answer from different people. But no one I
know claims we see 16.7 million colors, despite the fact we have 16.7
million different LAB values (equivalency) in your tagged test file.
Once converted to CMYK the number is around 6 million colors, which
is still on the very high end of any estimate for what we see. So
there is a very good chance that these numbers and their differences
are entirely meaningless, at this point. A metric has not been
applied to those numbers to determine their relevance either to human
vision, or to each other.
3.
This test is *incapable* of distinguishing between loss due to TRC
mismatch, and gain due to having shifted colors within a given color
space.
The Adobe RGB (1998) data is useless because the primaries are
different from ECI-RGB.
Question: Have you tried repeating this exact same test, but with a
source space defined by NTSC primaries and TRC defined by gamma 2.3?
2.4? 2.5? 2.6? 2.7? What were those results? Where was the peak? Were
more decimal places added to try and localize the actual peak?
Again, saying things doesn't make it true. Where's the proof of the
relevance of source space TRC to the TRC of the PCS used by the
output space? Given the PCS is at such a high precision level,
previously already we have established that TRC at high bit depth is
not relevant. How is it relevant in the PCS? The data is at very high
levels of precision.
Chris Murphy
. Still, I think counting unique value combinations
still is a
permittable method in this case (as long as the CMYK profile stays the
same of course), because in a CMYK profile's LUT for a given rendering
intent there technically can't be any duplicate (same Lab, different
CMYK) combinations (if I'm not very mistaken).
The problem is that you don't actually know what is being compared in
terms of human vision. In one you could have very spread out colors
that look very different, and in the other they could be packed so
close together that while yes they are different LAB values, they
aren't distinguishable LAB values. You don't actually know what you
have here. You're fitting a conclusion to match the results.
2. L* is effectively a greater gamma function
than gamma 1.8 and
shifts more of these 16.7 million encoded values to be darker.
That means shifting those colors further into the CMYK gamut.
By just assigning a color profile to an image file, certainly there
are
no values shifted at all. The values in the image file remain
unchanged. You therefore can't discern whether the lower
value for ECI-RGBv1 is
loss, or if the higher value for ECI-RGBv2 is gain due to this
shifting.
I think this statement actually in a way confirms the point regarding
encoding efficiency I made earlier, because there is no way of having
"better" values in this image file on which e.g. ECI-RGB v1 could
act in
a better way. The file already contains all possible values. The
higher
numerical result obtained with ECI-RGB v2 means just that, more of the
color values in the image file could actually be put to good use in
the
transform to CMYK. And that is exactly the point. Transformations take the PCS into account, and thus,
when converting
between profiles with different PCS, one can gain some benefits with a
input profile that inhabits some of the characteristics of the PCS of
the target profile. In the case of RGB with XYZ PCS to CMYK with Lab
PCS, the CMM first looks at the RGB triplet, determines the
corresponding XYZ values, converts these to Lab, then looks up the
CMYK
values corresponding to these Lab values (simplified, but still).
We're talking about floating point precision. You haven't
demonstrated that the TRC of the PCS is at all relevant with such a
high level of precision. Stating it's relevant doesn't make it
relevant. There are a number of examples indicating that it's not
relevant with such high bit depth.
and they are occurring through such a high level
of precision
as to make the TRC of the PCS totally irrelevant anyway.
But if that were the case, there would have been no numerical
benefit in
my examples when using ECI-RGB v2 versus the others. Adobe-RGB (gamma
2.2) comes somewhat close, but lower or higher gamma values I tried
couldn't reach the numerical results obtained with ECI-RGB v2. It's a
misconception? If it's a misconception then why bother even
having a debate over input TRC in the first place?
Input TRC still has relevance:
- regarding the TRC of the PCS of the target profile when converting
from RGB to CMYK
- when converting from RGB to RGB.