On Feb 18, 2008, at 2:30 AM, Florian Höch wrote:
True. Even when converting 8bpc data, the conversion is usually done
with 16 bits of precision internally by the CMM.
At least. Actually most of the transforms with ACE now use floating
point.
The major loss is at the output side, but not
exclusively. Let's take
the following RGB image, which contains all ~16.7 million colors
possible in any 8-bit three component colorspace:
http://hoech.net/files/rgb16mio.tif.zip
Now, lets assign different source profiles, then convert to the same
CMYK profile and count the number of resulting colors (all conversions
done in Photoshop CS3, CMM Adobe ACE, no dithering, actual counting of
color values via python script
http://hoech.net/files/image_countcolors.py.zip):
ECI-RGB v2 -> ISO Coated v2 (perceptual) = 6367638
Adobe-RGB -> ISO Coated v2 (perceptual) = 6045017
ECI-RGB v1 -> ISO Coated v2 (perceptual) = 5829371
ECI-RGB v2 -> ISO Coated v2 (rel. col. + black point comp.) = 5668910
Adobe-RGB -> ISO Coated v2 (rel. col. + black point comp.) = 5172835
ECI-RGB v1 -> ISO Coated v2 (rel. col. + black point comp.) = 4855199
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.
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. 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.
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.
Also, not sure how to run the python script. I get a message
"ImportError: No module named PIL"
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, and they are occurring through such a high level of precision
as to make the TRC of the PCS totally irrelevant anyway.
So it's not correct to suggest that output
device TRC is not
relevant to
loss when we are talking about 8bpc data.
It's the entire reason why we have any TRC instead of just pushing
unencoded (linear) data throughout our entire workflow.
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?
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.
Chris Murphy