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

[Michael Henning <drawoc darkrefraction com>]

You misunderstood my idea. I don't want babl to get specific
conversions for different ICC profiles; I want a generic mechanism to
take any ICC profile and turn it into a babl format. Øyvind indicated
that this is similar to how indexed formats already work (take a
palette and turn it into a babl format), so this wouldn't need vast
amounts of new code.

Part of why I suggested this is because it seems much more elegant
than tagging a newly loaded image as, say R'G'B'A when the image is
actually something else, like the code does now.

You can either place your patches on the bugtracker like you said, or
you can jump on irc and ask someone to apply them for you. You
probably want to separate your work out into one patch for each change
you make. (Although, feel free to lump a few small changes together if
they're related - it is possible to go overboard with the "separate
into tiny patches" mentality.)

  -- drawoc

On Sat, Jan 12, 2013 at 7:43 AM, Elle Stone <l elle stone gmail com> wrote:
> 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