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

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

On Thu, Nov 29, 2012 at 9:23 AM, Elle Stone <l elle stone gmail com> wrote:
> I posted a list of proposed additions/enhancements to the lcms.c plugin and
> would like some feedback on what to start working on next
> (http://ninedegreesbelow.com/temp/gimp-lcms-8.html). For instance,

*snip*

> *I haven't yet added in code that handles Gimp's 16-bit floating point and
> 32-bit integer image types. Are these image types being used by anyone?

16bit integer can perhaps be useful for various scientific
applications that GIMP thus far hasn't been well suited for. 16bit
floating point however is useful and widely used in for instance movie
production industry. It halves the storage/memory requirement compared
to 32bit float and isn't much less precise.

> *At present, the lcms.c plug-in only handles RGB images. I would like to add
> support for CMY(K), Gray-scale, LAB, and XYZ images. Are there any other
> higher priority candidates? Is there any reason why Gimp shouldn't be able
> to open LAB and XYZ images, at least to convert them to RGB and perhaps to
> convert them back when exporting? Also, I have almost no experience with
> CMYK and don't know how Gimp currently handles CMYK.

For 3 color component color models like LAB and XYZ what makes sense
to do is to convert to linear light RGB in floating point. Given that
GEGLs "RGB(A) float" format is unbounded doing this should not cause
any clipping of "out of gamut" colors. CMYK is a different story, but
a good start would be to convert CMYK to RGB on import, and keep track
of the profile so that it can be reapplied on export. This is
different from a native CMYK workflow, and the way we are trying to
steer GIMP in the future is to consider CMYK printing a subset of any
ink-based printing, thus CMYK is a special case of 4 inks on different
plates.

/Ø