Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality

[Elle Stone <l elle stone gmail com>]

On 11/29/12, Øyvind Kolås <pippin gimp org> wrote:
> On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone <l elle stone gmail com> wrote:
>> So gathering the gist of this discussion, it would be useful to add
>> the code for 16-bit floating point and 32-bit integer to the lcms
>> plug-in?
>>
>> And presumably if/when the lcms.c plug-in disappears, this particular
>> code could be transferred over (suitably modified, of course) to
>> whatever takes its place?
>
> I do not know the details of GIMP, but if the icc conversion handling
> moves into the GIMP core rather than a plug-in a lot of the code can
> be kept. Maybe what makes most sense is turning the logic of these
> transformations into GEGL operations, (that could be called by the
> GIMP core, or be re-used also outside GIMP). This way we might also
> make the generic image loader in GEGL responsible for inserting color
> conversion operations for its internal graph.). Turning the core-logic
> of the lcms.c plug-in into gegl-ops should be possible in such a way
> that at first GIMPs way of invoking the lcms plug-in continues working
> while the lcms plug-in uses the graph API of GEGL rather than directly
> operating on GeglBuffers.
>
> Creating custom babl formats for specific ICC profiles is possible,
> and would take a similar form to how babl/GEGL/GIMP currently deals
> with indexed images. With such an option the lcms code would move into
> a babl extension or become part of babl - this might be within the
> scope of babl, but I do like it's scope smaller striving to mostly do
> conversions between different pixel layouts and well defined color
> representations.

Even if babl could handle many of the more commonly used ICC profiles,
Gimp/gegl would still need to be able to handle ICC profile
conversions, because no matter how many specific ICC profiles babl is
modified to handle, there will still be ICC profiles that babl can't
handle. Consider custom or odd/unusual RGB working space profiles, the
plethora of CMYK profiles, and custom input (eg camera, scanner),
monitor, and output (eg printer) profiles. So it seems like creating
custom babl formats for specific ICC profiles would mean a lot of
extra code for babl, and Gimp/gegl would also need additional code to
check to see whether the requested ICC profile conversion was already
programmed into babl or not.

>
>> Where can I find the proper babl type for 16-bit floating point and
>> 32-bit integer? And what are the corresponding gegl iterator babl
>> formats for images with and without alpha channels? Is there a list
>> somewhere?
>
> If you click "Pixel formats" here http://gegl.org/babl/#Vocabulary you
> should get a list of the pixel formats babl has built in. The way
> these formats are expressed are rather consistent; though I do see
> that there could be some improvements to the documentation of how to
> manually decode a format string.

I looked at http://gegl.org/babl/#Vocabulary but didn't understand it.
However, adding in support for 16-bit floating point turned out to be
straightfoward:

      else if (type == babl_type ("half"))
        {
          if (has_alpha)
            {
              lcms_format = TYPE_RGBA_HALF_FLT;
              iter_format = babl_format ("R'G'B'A half");
            }
          else
            {
              lcms_format = TYPE_RGB_HALF_FLT;
              iter_format = babl_format ("R'G'B' half");
            }
        }

How/where do I submit a patch? Should I open an "lcms plugin
enhancement" bug report? Does Mitch want sequential small patches that
make one change at a time? Or does he want a bunch of changes all at
once?

I also coded in the ability to assign an ICC profile to a grayscale
image, and to convert grayscale images from one ICC profile to
another. Unfortunately the display-filter-lcms.c module disables color
management for the display of anything other than RGB images. However,
upon exporting the Gimp-converted grayscale image, krita opens and
displays the exported image correctly, and the image numbers look
right, so the actual lcms.c grayscale profile conversion code works.

I suppose what Gimp/gegl really wants is grayscale to RGB, CMYK to
RGB, etc, and then the other way upon exporting an image. Can gegl
handle grayscale images or n-channel images where "n" is greater than
3? Or does it always require 3 channels of information?

Although Gimp can convert an image from whatever starting precision to
16-bit floating point, there doesn't seem to be any way to export the
resulting image as 16-bit floating point or to import 16-bit floating
point images.

Is the Gimp/babl 16-bit floating point the same as OpenExr 16-bit
floating point? Is there a Gimp OpenExr plugin? Cinepaint outputs
16-bit floating point OpenExr tiffs, which Gimp opens as a 16-bit
*integer* image. The image requires an extreme white point/black point
adjustment and also a gamma correction to make it look like the
original image.

The fits format supports 32- and 64-bit integer and floating point;
OpenExr supports 32-bit integer and 32-bit floating point as well as
16-bit floating point. What bit-depth/precision does gegl use?

The lcms plugin code for 32-bit integer images would be just as simple
as the 16-bit floating point code, except it will probably require
writing a custom lcms_format. The lcms documentation on this procedure
is a bit too sparse for me to understand, so I'll have to ask on the
lcms mailing list.

Elle


-- 
http://ninedegreesbelow.com - articles on open source digital photography