3:32 a.m.
Hi list,
I have recently become aware of the change to the tone response curve
(TRC) in ECI-RGB to be defined by L*. Previously it was defined by a
gamma 1.8 function. I have had a number of conversations with
colleagues including color scientists and engineers about what makes
this compelling.
1.
On the face of it, it seems like L* is a good idea because it's
perceptually uniform and all that. But that's not the TRC of any of
our devices. And in an 8bpc context, that is the whole reason why we
having image encoding - is to deal with limitations of how our
devices actually behave today.
2.
Adding to confusion are two seeming contradictions on the ECI web site:
a.) "The focus of the eciRGB_v2 profile still is on the print and
publishing industry."
and
b.) "Especially 8 bit data using eciRGB 1.0 should be kept in eciRGB
1.0 as any colour space conversion will lead to at least some loss of
quality."
I consider these two statements seemingly in conflict because "print
and publishing industries" are almost entirely 8bpc only workflows,
and yet ECI-RGB v1 is recommended in an 8bpc context.
So when is ECI-RGB v2 recommended?
3.
High end retouching is being routinely performed with non-trivial
edits on linear encoded ProPhoto in 16bpc. What's the problem
exactly? On the face of it, it doesn't seem to apply to 16bpc
workflows at all.
4.
So I thought, maybe 16bpc edit, with 8bpc deliverable file workflow.
In a best case scenario I would tone map directly from a linear
editing space to the final print space, in 16bpc. Then drop to 8bpc
and deliver that file. That represents the least amount of loss of
levels through tone mapping.
So the question is, if I have a linear encoded image in 16bpc and
make a copy, take one copy and convert to ECI-RGBv1 and the other to
ECI-RGBv2, and then drop both to 8bpc; how similar are those two
image encodings to the final TRC of the output device I will likely
end up at?
The TRC of print and publishing industries are still close to that of
a curve defined by a gamma 1.8 function. Not L*. That's the current
reality of how print publishing actually behaves. Re-mapping from an
L* TRC to that of a typical print TRC results in more loss, than had
we mapped to an intermediate space that has a TRC close to typical
print TRC, that being one defined by gamma 1.8.
5.
I've seen no actual data on the ECI-RGB web site that demonstrates L*
based TRC is actually better, just a number of very strongly worded
claims:
"substantial advantages in the shadows"
"risk of posterization effects ... is significantly reduced"
These statements imply the inverse, that gamma 1.8 encoding has been
demonstrated to have substantial disadvantages in the shadows, and
risks of posterization is significantly increased. This is totally
specious and at this point, unproven. Where is the data proving this
either mathematically or in practice?
6.
L* does not represent the TRC of actual print tonality.
It would be nice if we could compel all of our devices to conform to
L*, but the fact is, they do not have this behavior. Human vision is
defined by L*, but device behavior is not, and that's why we encode
images, and why we have tone mapping in the first place. (Yes there
are a very small number of displays that can successfully be
compelled to have L* TRC, but still not print.)
This is supported even by information on the ECI web site:
"[ECI-RGBv1] offers equidistance, i.e. equal difference between two
color values in eciRGB mirrors an perceived equal difference when
these colors are seen by the human eye"
This is the same claim made by ECI-RGB v2 with respect to L* based
TRC, for the same market segment. Both cannot be true.
7.
In the case of closed-loop image editing, and *final* output to some
device that has an L* defined TRC, I see a benefit to L*. This is
hardly a new concept, as it's effectively used in medical imaging
(e.g. DICOM).
Closing statement:
In each of these areas I find that L* based TRC is either no better
or worse than what previous workflows have recommended, or results in
additional loss compared to previous workflows.
Further I find that this has made ECI-RGB confusing to the market to
differ only by one character, 1 or 2.
In an 8bpc workflow it's better to tone map to a TRC closer to final
output TRC to minimize the loss of levels through tone-remapping.
In a 16bpc workflow we have a lot of bits available, so TRC selection
is not particularly important (within reason.)
So the overriding question I have here is, why ECI-RGB v2? I don't
see it as being even remotely compelling over ECI-RGB v1, which I do
find compelling over both sRGB as well as Adobe RGB (1998). And the
reason I don't find it compelling is because I don't find an L* based
TRC to be compelling (i.e. I'd like to limit the conversation to that
of TRC rather than gamut, which is a separate issue).
Chris Murphy
3:12 a.m.
On Feb 16, 2008, at 9:38 PM, Roger Breton wrote:
Yes. It's actually a somewhat small modification, although the black
and CMY curves are different. GRACoL 2006 data for #1 stock
correlates very well with FOGRA 39. So I would not expect this to
translate to a very big difference. But this should be looked at more
closely before arriving at major workflow recommendation changes, in
my view.
Chris Murphy
6.
L* does not represent the TRC of actual print tonality.
Chris,
In light of IDEAlliance move to NDPC, do you find that your
statement still
hold? 
11:18 a.m.
Hello Chris Murphy, hello everyone,
1. On the face of it, it seems like L* is a good idea
because it's
perceptually uniform and all that. But that's not the TRC of any of
our devices. And in an 8bpc context, that is the whole reason why we
having image encoding - is to deal with limitations of how our
devices actually behave today.
Regarding TRC: This seems a moot point. TRCs for RGB working spaces
should be chosen for their encoding efficiency (I will detail this
further down), not by trying to match them to the TRC of any output
device, which would not make much sense in an ICC environment even if
the output device were to be a computer screen. This is because ICC
color conversion, e.g. for softproofing, always goes over L*a*b as
profile connection space (PCS), with the "conversion chain" being:
working space or image colorspace -> PCS -> simulation colorspace -> PCS
-> monitor colorspace. So *each* of these colorspaces would have to have
the same TRC characteristics for any benefits to carry through. Ideally,
that would be L*, because this is what the PCS uses. It also means that
if the first profile in the chain does not use L*, no benefit can be
gained by means of TRC, because the PCS characteristics can not be
changed. Also, offset printing like standardized by the ISO for example
has not really something like a single TRC, but rather slightly
different TRCs for CMY and K. In any case, direct correlating TRCs of
working spaces and device spaces seems not very meaningful.
2.
Adding to confusion are two seeming contradictions on the ECI web site:
a.) "The focus of the eciRGB_v2 profile still is on the print and
publishing industry."
and
b.) "Especially 8 bit data using eciRGB 1.0 should be kept in eciRGB
1.0 as any colour space conversion will lead to at least some loss of
quality."
I consider these two statements seemingly in conflict because "print
and publishing industries" are almost entirely 8bpc only workflows,
and yet ECI-RGB v1 is recommended in an 8bpc context.
I do not see the above statement as "recommendation of ECI-RGB v1 in an
8bpc context". I think it simply states that data which already exists
in ECI-RGB v1 (or in any other color space for that matter) should not
be converted, because each conversion will induce some quality loss
(which is the case with any conversion). This issue also exists with
16pbc data, but to a lesser extent.
3.
High end retouching is being routinely performed with non-trivial
edits on linear encoded ProPhoto in 16bpc. What's the problem
exactly? On the face of it, it doesn't seem to apply to 16bpc
workflows at all.
True, in 16bpc, some levels lost will never be as crucial as they might
be in 8bpc.
4.
So I thought, maybe 16bpc edit, with 8bpc deliverable file workflow.
In a best case scenario I would tone map directly from a linear
editing space to the final print space, in 16bpc. Then drop to 8bpc
and deliver that file. That represents the least amount of loss of
levels through tone mapping.
So the question is, if I have a linear encoded image in 16bpc and
make a copy, take one copy and convert to ECI-RGBv1 and the other to
ECI-RGBv2, and then drop both to 8bpc; how similar are those two
image encodings to the final TRC of the output device I will likely
end up at?
Again, I think it is not advisable to compare any RGB colorspace TRC to
the TRC of an output device directly if at any point ICC colormanagement
is involved.
5.
I've seen no actual data on the ECI-RGB web site that demonstrates L*
based TRC is actually better, just a number of very strongly worded
claims:
"substantial advantages in the shadows"
"risk of posterization effects ... is significantly reduced"
I agree that these are a bit strongly worded. Real world results might
not always show visible differences between ECI-RGB v1 and v2.
These statements imply the inverse, that gamma 1.8
encoding has been
demonstrated to have substantial disadvantages in the shadows, and
risks of posterization is significantly increased. This is totally
specious and at this point, unproven. Where is the data proving this
either mathematically or in practice?
Like said, maybe take with a grain of salt. It is true to some extent,
but a bit exaggerated in my eyes. To see the encoding efficiency of L*
versus Gamma 1.8 versus Gamma 2.2, I recommend to download the
documentation of the "LStar-RGB" profile from www.colormanagement.org.
The documentation is currently only available in german unfortunately,
but the image included alongside the PDF shows the comparison quite nicely:
http://colormanagement.org/download_files/LStar-Dokumentation.zip
6.
L* does not represent the TRC of actual print tonality.
See 1.
It would be nice if we could compel all of our devices to conform to
L*, but the fact is, they do not have this behavior.
One could try and adjust the TRC of output devices according to L* (at
least approximately), which would make the benefits gained on the
working colorspace side additionally available on the output side.
"[ECI-RGBv1] offers equidistance, i.e. equal
difference between two
color values in eciRGB mirrors an perceived equal difference when
these colors are seen by the human eye"
This is the same claim made by ECI-RGB v2 with respect to L* based
TRC, for the same market segment. Both cannot be true.
I think this is simply worded in an ambiguous way. True equidistance is
given only for ECI-RGB v2.
7.
In the case of closed-loop image editing, and *final* output to some
device that has an L* defined TRC, I see a benefit to L*. This is
hardly a new concept, as it's effectively used in medical imaging
(e.g. DICOM).
Closing statement:
In each of these areas I find that L* based TRC is either no better
or worse than what previous workflows have recommended, or results in
additional loss compared to previous workflows.
(...)
In an 8bpc workflow it's better to tone map to a TRC closer to final
output TRC to minimize the loss of levels through tone-remapping.
See also point 1. Lets rather talk about encoding efficiency and tonal
mapping. With L* encoding, highlights, midtones and shadows are all
encoded with the same emphasis (which means, at 8bpc, 16 levels RGB
always equal about 6 levels L*), other than with a specific gamma, which
will (to some extent) "emphasize" (compress) values of either
highlights, midtones or shadows and "sacrifice" (expand) some of the
others in return (which means for e.g. Gamma 1.8, 16 levels RGB equal 6
levels L* in the shadows but only 4 levels L* in the highlights).
Furthermore, ICC color conversion always goes over L*a*b as profile
connection space. So the encoding efficiency of the input profile will
have an influence on the result. L* is a very efficient encoding
regarding spread of tonal values because the L* axis of the input data
can be mapped directly to the L* axis of the profile connection space
(PCS). No (single) gamma value can do that, so at this stage, with
gamma-based input profiles, some levels will be lost, but not with L*.
There will still be levels lost because of differences between PCS
characteristics and output space characteristics of course, but this
will be the case with any input profile and there will be fewer levels
lost overall if the input profile is "L*-based". If this translates into
visible benefits depends also on the images being converted though, so
one might not notice any differences.
In a 16bpc workflow we have a lot of bits available,
so TRC selection
is not particularly important (within reason.)
Agreed.
So the overriding question I have here is, why ECI-RGB
v2? I don't
see it as being even remotely compelling over ECI-RGB v1, which I do
find compelling over both sRGB as well as Adobe RGB (1998). And the
reason I don't find it compelling is because I don't find an L* based
TRC to be compelling (i.e. I'd like to limit the conversation to that
of TRC rather than gamut, which is a separate issue).
Of course, profile choice is also workflow- and maybe personal taste
dependant. There is no real reason to switch from any profile currently
in use to ECI-RGB v2 if the results obtained with the other profile are
satisfying. But for "new" users looking for an RGB working space,
ECI-RGB v2 can imho be recommended instead of ECI-RGB v1.
Kind regards,
Florian Höch
3:28 a.m.
On Feb 17, 2008, at 5:18 AM, Florian Höch wrote:
TRCs for RGB working spaces
should be chosen for their encoding efficiency (I will detail this
further down), not by trying to match them to the TRC of any output
device, which would not make much sense in an ICC environment even if
the output device were to be a computer screen. This is because ICC
color conversion, e.g. for softproofing, always goes over L*a*b as
profile connection space (PCS), with the "conversion chain" being:
working space or image colorspace -> PCS -> simulation colorspace -
Except that the PCS is not always L*a*b*. It can also be XYZ. So I
don't see how it can be true that it should "ideally" be L* based.
Case in point, ECI-RGB, both v1 and v2 have defined the PCS as XYZ,
not LAB.
Also, the data does not actually get converted to the PCS, ever. The
PCS is just a means to an end. It allows a colorworld to be created
between a source and destination space. Image data is converted
directly from source to destination. It does not actually get passed
through LAB or XYZ as an intermediary color space. Further the PCS
and the colorworld in practice are always 16bpc of precision or
greater to prevent even greater quantization errors than will already
be the case as result of TRC differences between source and destination.
Any loss is not on the conversion to or from the PCS. The loss is at
the output side. If its TRC is mismatched from the source, you will
have loss of levels. If you don't have 16bpc in the PCS the loss is
even greater, but we can ignore this because in practice those
conversions are through at least 16bpc of precision.
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.
Chris Murphy
PCS
-> monitor colorspace. So *each* of
these colorspaces would have to
have
the same TRC characteristics for any benefits to carry through.
Ideally,
that would be L*, because this is what the PCS uses.
8:30 a.m.
Except that the PCS is not always L*a*b*. It can also
be XYZ. So I don't
see how it can be true that it should "ideally" be L* based. Case in
point, ECI-RGB, both v1 and v2 have defined the PCS as XYZ, not LAB.
The PCS is Lab atleast for all CMYK output profiles I know (there might
be exceptions). RGB input/working space profiles mostly have XYZ as PCS
(which has mathematical efficiency reasons afaik). Both colorspaces (XYZ
and Lab) can be converted into the other. As far as the PCS is
concerned, one needs to consider the PCS of the output profile.
Also, the data does not actually get converted to the
PCS, ever. The PCS
is just a means to an end. It allows a colorworld to be created between
a source and destination space. Image data is converted directly from
source to destination. It does not actually get passed through LAB or
XYZ as an intermediary color space.
True. The values are directly looked up through the profiles matrix or LUT.
Further the PCS and the colorworld
in practice are always 16bpc of precision or greater to prevent even
greater quantization errors than will already be the case as result of
TRC differences between source and destination.
True. Even when converting 8bpc data, the conversion is usually done
with 16 bits of precision internally by the CMM.
Any loss is not on the conversion to or from the PCS.
The loss is at the output side.
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. I have tested other input/output profile combinations with
similar results. The image is synthethic, but in real-world images the
correlations are the same. I chose the synthetic image because it
illustrates the point really good (real-world differences are not as
large, because real-world images contain less colors).
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.
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. Direct RGB-RGB conversions
are another matter, there the said correlation of input and output TRC
is given).
Best regards,
Florian Höch
8:30 p.m.
On Feb 18, 2008, at 2:30 AM, Florian Höch wrote:
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.
It's a misconception? If it's a misconception then why bother even
having a debate over input TRC in the first place?
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. 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. 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
11:25 a.m.
Hello Chris,
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).
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).
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.
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
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.
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. 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? 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.
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. 
1:20 p.m.
New subject: REMOVE
Please unsub me immediately. Thanks.
-----Original Message-----
From: eci-en-bounces(a)lists.callassoftware.com
[mailto:eci-en-bounces@lists.callassoftware.com] On Behalf Of Chris
Murphy
Sent: Wednesday, February 20, 2008 2:28 PM
To: eci-en(a)lists.callassoftware.com
Subject: Re: [ECI-EN] L*, ECI-RGB v2
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
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.callassoftware.com
http://lists.callassoftware.com/mailman/listinfo/eci-en
. 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.
5:51 p.m.
Hello Chris,
that's conclusive, I have nothing to add. Thanks for the elaborate
explanations!
This time I will not assert anything at all, just post a test case and
kindly ask for your (and of course, anybody else's) input on the test
case itself and the results.
Testing image: Linear gray ramp, Lab, 256 levels at 8bpc
http://hoech.net/files/Linear_Gray_Ramp_Lab.tif.zip
Tests and results (levels after conversion):
Converting (RI=perceptual, if not otherwise stated)...
to ECI-RGB v1: 225
to ECI-RGB v1 rel.col+bpc: 225
to ECI-RGB v1, then ISO Coated v2 (ECI): 224
to ECI-RGB v1, then ISO Coated v2 (ECI) rel.col.+bpc: 225
to 16bpc, then ECI-RGB v1, then ISO Coated v2 (ECI), then 8bpc: 256
to 16bpc, then ECI-RGB v1, then ISO Coated v2 (ECI) rel.col.+bpc, then
8bpc: 256
to ECI-RGB v1 with gamma=2.3: 236
to ECI-RGB v1 with gamma=2.3, then ISO Coated v2 (ECI): 235
to ECI-RGB v1 with gamma=2.3, then ISO Coated v2 (ECI) rel.col.+bpc: 236
to ECI-RGB v1 with gamma=2.4: 237
to ECI-RGB v1 with gamma=2.4, then ISO Coated v2 (ECI): 237
to ECI-RGB v1 with gamma=2.4, then ISO Coated v2 (ECI) rel.col.+bpc: 237
to ECI-RGB v1 with gamma=2.5: 236
to ECI-RGB v1 with gamma=2.5, then ISO Coated v2 (ECI): 236
to ECI-RGB v1 with gamma=2.5, then ISO Coated v2 (ECI) rel.col.+bpc: 236
to eciRGB v2: 256
to eciRGB v2 rel.col+bpc: 256
to eciRGB v2, then ISO Coated v2 (ECI): 256
to eciRGB v2, then ISO Coated v2 (ECI) rel.col.+bpc: 256
(regarding the tests with ECI-RGB v1 and custom gamma, I tested gamma
values 2.0 - 2.6 and then only included the results at the peak and
around, I hope that's ok)
Kind regards,
Florian Höch
8:16 p.m.
On Feb 21, 2008, at 11:51 AM, Florian Höch wrote:
This time I will not assert anything at all, just post
a test case and
kindly ask for your (and of course, anybody else's) input on the test
case itself and the results.
That really doesn't work either, because then the test has zero
context and no assertion as to what it is supposed to demonstrate.
Scientists don't just do tests without stating a purpose for the
test, how the test is going to be carried out, potential problems
with the test, etc.
So now it is totally unclear what your point is in presenting this
data. The context is not stated. We just have data. So what?
Testing image: Linear gray ramp, Lab, 256 levels at 8bpc
http://hoech.net/files/Linear_Gray_Ramp_Lab.tif.zip
First you start out with data that is by definition encoded to a TRC
defined by L*. And you're going to end up in a space with TRC defined
by L*. It is obvious that you will have no loss, and it's because the
source data in 8bpc and the ending data in 8bpc have the same
encoding. It's exactly what I've been saying about the importance of
source-destination TRC match when the data is limited to 8bpc.
If you do this test with ECI-RGBv1 going to ColorMatch RGB you will
get the same number of gray levels in as you do out. 256.
Your test does *NOT* prove your assertion that the PCS TRC is
relevant in a high precision context. Case in point, if you uses ACE
for this test, your image data is being converted from LAB to XYZ
since that is the PCS for ECI-RGBv2. And XYZ uses linear encoding.
There is no gamma function, there is no L* function. The fact that it
didn't cause level loss is because the image data is at a very high
level of precision.
What I'd rather see is go back to the color test from previous
postings. A color space defined with NTCS primaries and varying TRC's
defined by gammas 2.3 through 2.6. So just like ECI-RGB, except
varying the TRC, and converting to the ISO Coated (ECI) profile, with
all the same parameters as the previous tests. Again, I'd do this
myself but it's not clear how to use the python script on Mac OS. I
have acquired PIL and installed it, but now when I run the script I get:
im = Image.open(sys.argv[1])
IndexError: list index out of range
Chris Murphy
9 p.m.
Hello Chris,
That really doesn't work either, because then the
test has zero
context and no assertion as to what it is supposed to demonstrate.
Ok, but that is actually what I was interested in (if it was at all
feasible).
What I'd rather see is go back to the color test
from previous
postings. A color space defined with NTCS primaries and varying
TRC's defined by gammas 2.3 through 2.6. So just like ECI-RGB,
except varying the TRC, and converting to the ISO Coated (ECI)
profile, with all the same parameters as the previous tests.
Ah! Ok, then I misunderstood you. I thought that such a test would still
have the problems of relevance.
Again, I'd do this myself but it's not clear
how to use the python
script on Mac OS. I have acquired PIL and installed it, but now when I
run the script I get:
im = Image.open(sys.argv[1])
IndexError: list index out of range
Sorry, I realize I should have posted that earlier.
For Mac OS X I guess the call would be something like (from Terminal):
/python_directory/python image_countcolors.py path/to/imagefile.tif
Oh, and just to reiterate: I stated in my previous post that I actually
see your points (really!), thus, I was trying to make no assertions to
begin with (I see now that you thought I was trying to prove my initial
assertions by posting the results. I should have only posted the image
and what I would do with it, then ask if such a test would be feasible
and if it would actually yield any meaningful results). I really just
wanted some input (which I got now, so, again, thanks).
Kind regards,
Florian Höch
12:03 a.m.
On Feb 21, 2008, at 3:00 PM, Florian Höch wrote:
Well actually it would! :-) But the point is that if we get even more
CMYK values with one of those gamma values, then it's a demonstration
that the test is a problem.
I remain convinced we need a test that differentiates between the
loss of levels due to change of TRC, and the gain of encoded CMYK
values due to change of TRC.
We need to know if we even care about these 5 million or 6 million
colors as well.
What I'd rather see is go back to the color
test from previous
postings. A color space defined with NTCS primaries and varying
TRC's defined by gammas 2.3 through 2.6. So just like ECI-RGB,
except varying the TRC, and converting to the ISO Coated (ECI)
profile, with all the same parameters as the previous tests.
Ah! Ok, then I misunderstood you. I thought that such a test would
still
have the problems of relevance. /python_directory/python image_countcolors.py
path/to/imagefile.tif
This appears to be working. No error message after 1 minute and
python process is soaking up 60% of CPU.
Oh, and just to reiterate: I stated in my previous
post that I
actually
see your points (really!), thus, I was trying to make no assertions to
begin with (I see now that you thought I was trying to prove my
initial
assertions by posting the results. I should have only posted the image
and what I would do with it, then ask if such a test would be feasible
and if it would actually yield any meaningful results). I really just
wanted some input (which I got now, so, again, thanks).
Ah OK. No worries.
I would like to believe that whoever has pushed this L* idea onto the
ECI, and those who have voted on it, and in particular whoever on the
ISO committee looked at it, before making it an ISO standard, would
have very clear and reproducible evaluation that would demonstrate
why it's better, when it's better, when it's not better, etc. I
haven't seen anything like that yet.
Chris Murphy
11:40 a.m.
Hello Chris, Florian,
Am 18.02.2008 um 03:28 schrieb Chris Murphy:
<snip>
Also, the data does not actually get converted to the PCS, ever. The
PCS is just a means to an end. It allows a colorworld to be created
between a source and destination space. Image data is converted
directly from source to destination. It does not actually get passed
through LAB or XYZ as an intermediary color space.
<snip>
Not true if you use relative colorimetric with black point compensation.
At least using the Adobe products splits the transform into two
transforms
source -> Lab, Lab -> destination.
Regards
Rolf Gierling
-----------------------------------------------------
Multitools
Dipl.-Ing. Rolf Gierling
Colormanagement
Consulting - Development - Distribution
Mariabrunnstr. 16
52064 Aachen
Germany
Tel. +49 (0) 2 41 / 4 01 25 79
Fax. +49 (0) 2 41 / 4 01 25 83
mail(a)multitools-online.de
www.multitools-online.de
Author of "Farbmanagement"
3rd Edition July 2006
mitp Verlag, Bonn
ISBN 3-8266-1626-X
1:21 p.m.
Interesting, and makes sense. The black point compensation has to be
incorporated some way, but I didn't know actually how :)
Thanks for the insight.
Regards
Florian Höch
Rolf Gierling schrieb:
Hello Chris, Florian,
Am 18.02.2008 um 03:28 schrieb Chris Murphy:
<snip>
Also, the data does not actually get converted to the PCS, ever. The
PCS is just a means to an end. It allows a colorworld to be created
between a source and destination space. Image data is converted
directly from source to destination. It does not actually get passed
through LAB or XYZ as an intermediary color space.
<snip>
Not true if you use relative colorimetric with black point compensation.
At least using the Adobe products splits the transform into two
transforms
source -> Lab, Lab -> destination.
Regards
Rolf Gierling
-----------------------------------------------------
Multitools
Dipl.-Ing. Rolf Gierling
Colormanagement
Consulting - Development - Distribution
Mariabrunnstr. 16
52064 Aachen
Germany
Tel. +49 (0) 2 41 / 4 01 25 79
Fax. +49 (0) 2 41 / 4 01 25 83
mail(a)multitools-online.de
www.multitools-online.de
Author of "Farbmanagement"
3rd Edition July 2006
mitp Verlag, Bonn
ISBN 3-8266-1626-X
_______________________________________________
ECI-EN mailing list
ECI-EN(a)lists.callassoftware.com
http://lists.callassoftware.com/mailman/listinfo/eci-en
10:20 p.m.
On Feb 18, 2008, at 5:40 AM, Rolf Gierling wrote:
Hello Chris, Florian,
Am 18.02.2008 um 03:28 schrieb Chris Murphy:
False.
Adobe's BPC is done in XYZ, not LAB. The correction is wedged between
the two profiles. A single colorworld is still created - not two. So
image data is converted directly from device1 values to device2
values. It's like a devicelink profile that has been created in memory.
Chris Murphy
<snip>
Also, the data does not actually get converted to the PCS, ever. The
PCS is just a means to an end. It allows a colorworld to be created
between a source and destination space. Image data is converted
directly from source to destination. It does not actually get passed
through LAB or XYZ as an intermediary color space.
<snip>
Not true if you use relative colorimetric with black point
compensation.
At least using the Adobe products splits the transform into two
transforms
source -> Lab, Lab -> destination.
2:29 p.m.
Am 19.02.2008 um 22:20 schrieb Chris Murphy:
On Feb 18, 2008, at 5:40 AM, Rolf Gierling wrote:
I never said that BPC is done in Lab. Adobe's techdoc about
BPC clearly says that it's done in XYZ internally.
Fact is, if I use convert to profile in Photoshop CS2 from
Adobe RGB (1998), Matrics based, PCS XYZ to
ISO Coated v2 (ECI), LUT based, PCS Lab,
relative colorimetric with black point compensation,
my Logging Color Management Module on Windows AND Mac outputs
the following, which can be pretty much divided into the following
parts:
Computation of Black Point Compensation:
RGM CMM: src: Adobe RGB (1998), dst: Lab D50, srcRI: 1 dstRI: 1
RGM CMM: src: ISO Coated v2 (ECI), dst: Lab D50, srcRI: 1 dstRI: 1
RGM CMM: src: Lab D50, dst: ISO Coated v2 (ECI), srcRI: 0 dstRI: 0
RGM CMM: src: Lab D50, dst: ISO Coated v2 (ECI), srcRI: 1 dstRI: 1
Preview:
RGM CMM: src: Adobe RGB (1998), dst: Lab D50, srcRI: 1 dstRI: 1
RGM CMM: src: Lab D50, dst: ISO Coated v2 (ECI), srcRI: 1 dstRI: 1
Conversion:
RGM CMM: src: Adobe RGB (1998), dst: Lab D50, srcRI: 1 dstRI: 1
RGM CMM: src: Lab D50, dst: ISO Coated v2 (ECI), srcRI: 1 dstRI: 1
which are clearly two separated conversions running through my CMM.
Regards
Rolf Gierling
-----------------------------------------------------
Multitools
Dipl.-Ing. Rolf Gierling
Colormanagement
Consulting - Development - Distribution
Mariabrunnstr. 16
52064 Aachen
Germany
Tel. +49 (0) 2 41 / 4 01 25 79
Fax. +49 (0) 2 41 / 4 01 25 83
mail(a)multitools-online.de
www.multitools-online.de
Author of "Farbmanagement"
3rd Edition July 2006
mitp Verlag, Bonn
ISBN 3-8266-1626-X
Hello Chris, Florian,
Am 18.02.2008 um 03:28 schrieb Chris Murphy:
False.
Adobe's BPC is done in XYZ, not LAB. The correction is wedged between
the two profiles. A single colorworld is still created - not two. So
image data is converted directly from device1 values to device2
values. It's like a devicelink profile that has been created in
memory. <snip>
Also, the data does not actually get converted to the PCS, ever. The
PCS is just a means to an end. It allows a colorworld to be created
between a source and destination space. Image data is converted
directly from source to destination. It does not actually get passed
through LAB or XYZ as an intermediary color space.
<snip>
Not true if you use relative colorimetric with black point
compensation.
At least using the Adobe products splits the transform into two
transforms
source -> Lab, Lab -> destination.
9:08 p.m.
On Feb 20, 2008, at 8:29 AM, Rolf Gierling wrote:
I never said that BPC is done in Lab. Adobe's
techdoc about
BPC clearly says that it's done in XYZ internally.
OK.
which are clearly two separated conversions running
through my CMM.
OK I asked an Adobe engineer about it and he says different CMM's do
different things apparently. And in the case of ACE it does move all
data through all intermediate steps in floating point. So actually
the image data itself may go through XYZ and/or LAB in this case.
Some stages can be optimized away.
Still, it is an unproven assertion that the TRC of the PCS is somehow
important given conversions occur in floating point.
Chris Murphy
12:49 p.m.
New subject: L*, ECI-RGB v2, TRC of print output
Hello Chris,
Could You please refer to a source, which state, that the FOGRA, GRACoL,
SWOP, IFRA reference printing conditions have a TRC close to Gamma 1,8 ?
I´m especially interested on a formula to calculate the nearest "Gamma"
from print characterization-data which refers to ISO standards and CIE
research.
Regards
Jan-Peter
Chris Murphy wrote:
The TRC of print and publishing industries are still close to that of
a curve defined by a gamma 1.8 function. Not L*. That's the current
reality of how print publishing actually behaves. Re-mapping from an
L* TRC to that of a typical print TRC results in more loss, than had
we mapped to an intermediate space that has a TRC close to typical
print TRC, that being one defined by gamma 1.8.
--
*********** Neue Adresse / new adress ************
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Christinenstr. 21 ------ http://www.colormanagement.de
10119 Berlin -------- mailto:homann@colormanagement.de
*********** Neue Adresse / new adress ************
5915
days inactive
5924
days old
eci-en@lists.callassoftware.com
19 comments
6 participants
participants (6)
-
Carl Kuramoto -
Chris Murphy -
Florian Höch -
Jan-Peter Homann -
Roger Breton -
Rolf Gierling