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