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