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 -
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.
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