Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Elle Stone <l elle stone gmail com>]

I keep coming back to this question. If your goal is to convert all
images to your linear light working space for image processing, why
not do the conversion one time and be done with it?

I did some preliminary checking. LCMS can do the conversion between
your linear light profile and the monitor profile. At least I think it
can, per this post:

[Lcms-user] negative float clipping and gamma 1.0
http://sourceforge.net/mailarchive/message.php?msg_id=29167076

So it looks like LCMS can now convert from linear gamma built-in sRGB
with negative values to XYZ space. I played with the transicc utility
and sure enough, negative numbers were being transformed from linear
sRGB to XYZ and back. I'm pretty sure any other profile with a linear
gamma TRC will also work.

Assuming the new LCMS capacity works the way I think it does, then you
could use what Jon Nordby described in a previous post to this thread,
and let LCMS take care of sending the properly transformed linear
light information to the monitor display:

On 8/30/12, Jon Nordby <jononor gmail com> wrote:
> This is actually one more conversion and one step earlier than we need
> to. Ideally the pipeline should look like this:
>
> GeglBuffer -> | display filter stack | -> sRGB in monitor profile -> | Cairo
> |
>
> That way we only convert to the monitor profile as a last step. This
> would require GEGLifying the display filter stack and all the modules
> it uses.

(I think "sRGB in monitor profile" probably means "sRGB or monitor
profile". Jon - yes? no?)

This ability to use negative floating point numbers with a linear
gamma profile (only a linear gamma profile, no other TRC) is a new
LCMS capability. It would not have been around at all when you thought
up your linear light profile, which perhaps MS/HP then "borrowed" from
you. :)

Perhaps the new LCMS capability would eliminate any need for
constantly converting back and forth between sRTB TRC and linear gamma
TRC.

> You should also note that babl's "RGBA float" format is not inspired
> by or defined by scRGB, but could more well be described as a linear
> light / physical color space, with the same RGB primaries as sRGB, a
> linear gamma curve, white at 1.0, 1.0, 1.0 - black at 0,0,0 extendable
> towards the limits of floating point representation negatively and
> positively.

Your choice of white point (1,1,1) is intriguing, being at odds with
the almost universally used D50 white point of
XYZ=(96.420,100.000,82.489), and also the V2 sRGB D65. By the way, the
lcms V4 matrix sRGB profile uses D50, in keeping with the V4 ICC
profile specifications.

Are the primaries for your linear light profile as defined in
babl/extensions/CIE.c?
/* sRGB/HDTV phosphor colours */
static const double pxr = 0.64F;
static const double pyr = 0.33F;
static const double pxg = 0.30F;
static const double pyg = 0.60F;
static const double pxb = 0.15F;
static const double pyb = 0.06F;

If so, I will experiment to see what happens using lcms utility
"transicc" to convert from your linear light space with its unusual
white point, to regular color spaces (including camera and monitor as
well as working spaces), and back.

Just a thought: If your linear space used the identity profile, with
RGB primaries of (1,0,0), (0,1,0) and (0,0,1), I don't think you would
need negative float values to cover the entire 1931 CIE XYZ color
space, conversion computations would be drastically simplified, and
I'm pretty sure you'd have less space devoted to imaginary colors. But
this whole negative floating point values thing for ICC profiles is
new territory to me. I've known about it theoretically for a long
time, but until now never had the wherewithal (the new LCMS
utilities/capabilities) or reason (your linear light color space) to
acquire any practical understanding.

Cheers,
Elle Stone


-- 
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography