Re: [Gimp-developer] the Gimp lcms.c plug-in

[Elle Stone <l elle stone gmail com>]

On 8/27/12, Øyvind Kolås <pippin gimp org> wrote:

> On Mon, Aug 27, 2012 at 4:08 PM, Elle Stone <l elle stone gmail com> wrote:
>> My lcms2 plug-in now does do correct ICC profile conversions, from any
>> RGB color space, to any RGB color space, at 8-bit integer, 16-bit
>> integer, and 32-bit floating point.
>>
>> However, to get it to work, I had to modify the babl/babl/util.h file.
>
> This is great news, since it means that the code works as intenended
> but probably with slightly different intentions.

Could you clarify? which code works with which intentions?


>> After modifying the babl/babl/util.h file, 16-bit tiffs open
>> correctly. As you might recall, with the default util.h file, 16-bit
>> tiffs open with a mysterious and erroneous "gamma=2.2 correction"
>> having been applied. This tiff issue has nothing to do with the lcms
>> plug-in.
>
> Data stored for higher bitdepths per pixel than 8 are assumed to be
> stored with a linear gamma ramp,

ICC V2 matrix profiles (simplest case here) have two parts that are
relevant to the present discussion:

1. They have RGB/XYZ primaries, the chromaticity coordinates that
"interpret" if you will the chroma part of the image RGB values.

2. They have a tone response curve (TRC) that determines how fast the
image RGB tonality approches maximum white, starting from minimum
black, as the RGB values go from 0 to whatever maximum value is
allowed by the bit-depth of the image.

Also, the sRGB V2 matrix ICC profile has a 1024 point TRC that is
contained in the sRGB profile TRC tags; this sRGB TRC can be exported
and then imported into another ICC profile to change the other
profile's TRC, to create a variant of the other profile that has the
other profile's primaries, but the sRGB TRC.

The *only* time the default babl code properly converts an image from
one ICC profile to another is if two conditions are met:

1. The primaries are the same in the source and destination profiles.
2. The TRCs of the two profiles are either linear gamma or the sRGB TRC.

So if I create a scarse prophoto variant that has a TRC equal to the
sRGB TRC instead of being equal to gamma=1.8, and a second variant
that has a linear gamma TRC, I can use the default babl code to
convert from linear prophoto to the special prophoto variant with the
sRGB TRC and back again.

If I create a variant of ClayRGB that has a linear gamma TRC and a
second variant that has the sRGB TRC, I can use the default babl code
to convert from linear gamma ClayRGB to the special ClayRGB variant
with the sRGB TRC and back again.

All other ICC profile conversions are wrong if done with the default
babl code, but correct if I modify the /babl/babl/util.h file.

In particular, if I keep the TRC as linear gamma for the source and
destination profile, but the primaries vary, the colors are wrong.

And if I keep the primaries the same for the source and destination
profile, but the TRCs are anything other than linear gamma and the
sRGB TRC, the tonality comes out wrong.

And if both the primaries and the TRC vary, then everything is wrong.
Unless I modify the util.h file. Then everything is right.

> a higher level code where you
> probably could do a similar tweak without changing core babl behavior
> could be in ... digging through GIMP code ...
> gimp/app/gegl/gimp-babl.c which contains code determining the data
> expected to be managed, for all arbitrary profile source imagery it
> would be recommended to store layer data in floating point.

I don't think there is any way to tweak the Gimp code to undo the
effect of the util.h code that converts "something" in the background
from a linear gamma TRC to the regular sRGB TRC and back. But perhaps
if I had a better understanding of what the default babl code in
babl/babl/base/util.h, and also in fast-float.c and float.c, is
supposed to accomplish, it would help. Can anyone give a summary?

> /Øyvind K.

Elle