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

[Øyvind Kolås <pippin gimp org>]

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.

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

>>Going forward, AFAIK, the "image->mode->assign/convert color profile"
>>menu entries should be removed from the lcms plugin, and everything
>>automatically converted to srgb/R'G'B' on import.
>
> Automatically converting an image to (extended) sRGB if it had the
> wrong embedded profile would mean the image now has the wrong colors.
> Likewise with automatically assigning sRGB to an image that doesn't
> have an embedded profile, unless the image really is an sRGB image.
>
> Also, presumably upon export you still need to give the user the
> option to export to a color space other than sRGB.  The only time I
> use sRGB as an output space is when preparing an image for the web.

Yep, what most people consider working-space in other applications
would become an "target-space" this would be the desired color space
and gamut, soft-proofing, out-of-gamut indications etc. should be
working with the knowledge of the gamut of this space. The mechanics
of defaults for this target-space, based on imported images or
preferred own defaults needs to be considered from a UX point of view.

> Presumably converting an image to the "extended" sRGB color space
> won't clip, for example, the colors in a ProPhoto image or an image
> that is still in the camera input space. But exporting the image as
> pure regular sRGB certainly could (and very often would) clip colors.

Yep, which is why when the display-filters of GIMP is revisited and
turned into a chain of GEGL ops, we need to look into gamut warnings
and soft-proofing taking the target-profile into account.

/Ø
--