Hello Chris,
So, of the
three RGB profiles the least levels are lost with the
ECI-RGB
v2 profile.
That assertion is not at all demonstrated by these results. The test
is flawed in numerous ways.
1. Python code seems to count unique CMYK values, not unique colors
to human vision. There will be many CMYK values that are redundant.
I do not know a reliable way to count colors unique to human vision,
because this also depends on the viewer. One person still might see a
difference between two different colors, whereas the other might
perceive them as the same. Also, in CMYK, same color values (as in, same
XYZ or Lab coordinates) can be achieved with different amounts of CMY
and K. 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).
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.
What profile is "ISO Coated v2"? I don't
see this installed by
default in my system, or included with ECI_Offset_2007. There is "ISO
Coated v2 (ECI)" and there is "ISO Coated v2 300% (ECI)". So it's not
clear what profile I should use.
Sorry for the ambiguity, I tend to forget that ECI offers two ISO Coated
v2 profiles. I used "ISO Coated v2 (ECI)", not the "300%" one.
Also, not sure how to run the python script. I get a
message
"ImportError: No module named PIL"
It might be missing. PIL (Python Imaging Library) can be obtained here:
http://www.pythonware.com/products/pil/
(btw, have patience when using the count colors script. Depending on the
actual amount of colors in the image, it can be really painfully slow)
If its TRC is mismatched from the source, you will
have
loss of levels.
I have to disagree, because of the reasons I already mentioned and
also
the examples above. The optimal TRC on the input side depends on
the PCS
of the output profile.
There is no demonstration of this at all, or explanation why it would
be the case. Just assertion. This isn't how transformations actually
occur
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).
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.
I agree
partly, output device TRC is of course not irrelevant. But the
notion that input profile TRC has to correspond in the best
possible way
to output profile TRC to minimze loss, is a misconception (when
converting from RGB to CMYK or vice versa.
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.
Direct RGB-RGB
conversions
are another matter, there the said correlation of input and output TRC
is given).
Why does it matter with RGB to RGB and not with RGB to CMYK? There
are clearly TRC discrepancies in both instances.
With RGB to RGB conversions, we have the same number of channels,
additive colorants, and the same PCS (XYZ), on both sides. I think these
are important differences. They are reason why in that case, same TRC
values in the actual colorspaces yield better results in conversions (if
the gamuts are not too different I think).
Kind regards,
Florian Höch