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@xxxxxxxxx> 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 _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
