Re: [Gimp-developer] GIMP and Adobe RGB (1998)

[Elle Stone <ellestone ninedegreesbelow com>]

On 04/17/2014 10:02 AM, Øyvind Kolås wrote:
> On Thu, Apr 17, 2014 at 1:08 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > The other day there was an IRC discussion of the possibility of GIMP
> > supporting RGB color spaces other than unbounded mode sRGB.
> >
> > I was surprised to see in the transcript a statement that GIMP shouldn't
> > support Adobe RGB (1998).
>
> It makes no sense to import opening files with any particular ICC
> profile, by definition unbounded gamut RGB spaces support storing and
> manipulating all colors of photo's/imagery of any bounded gamut RGB
> spaces.

Storage, yes. Unbounded mode sRGB can be used to store any colors. So 
can any other unbounded mode color space.

Manipulation works for some operations, but not for all operations.

*Some* editing operations work exactly the same in any floating point 
unbounded mode color space. sRGB is no more and no less special in this 
regard than any other RGB color space.

Many important editing operations *fail* in unbounded mode sRGB because 
*the channel data has been rearranged*. I've given concrete examples and 
provided files so anyone can replicate my findings:
http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.html

The shape and distribution of channel data matters.

> What actual color space/pixel format is being used for
> manipulation is a separate concern from how color data is passed
> around and actually stored.
> There are definetely many things to sort
> out and many things in GIMP that have are straight ports of the old
> 8bit/component code; keeping track of the _meta_data_ of an original
> color space/gamut/pixel format raster data originated in - and the
> ability to to chosen/select operations in that space is something that
> fits the strongly color managed architecture of GEGL. While doing
> global overrides of some of the internal pixel formats that are
> absolutely colorimetrically defined

What pixel formats are absolutely colorimetrically defined?

Could you please explain what you mean by absolute colorimetric? Apart 
from soft proofing to an output device profile, I'm just not sure how 
the words "absolute colorimetric" apply in the current context.


> would make it easy to misconfigure
> the color settings yielding surprising and inconsistent behavior.

? I don't understand what you mean. Is it the user who misconfigures 
something? Or the code?

> > Adobe RGB (1998) is important for:
> >
> > * People preparing images for printing
>
> The default GEGL/babl pixel formats in floating point are unbounded;
> and personally I think the 16bit formats should be made 4.12 instead
> 0.16 fixed point

My apologies, what do you mean? Are you planning on making 16-bit 
integer precision actually 12-bit integer or something? Or some kind of 
hybrid integer-floating point?


> to provide adequate headroom/footroom - though with a
> predominantely floating point based processing doing this might not be
> a huge win.
>
> > * People who save Adobe RGB (1998) camera jpegs

Well, I thought I made it clear that I was talking about 
camera-generated jpegs - that were save to disk by the camera - already 
in the Adobe RGB (1998) color space. Exporting the image after editing 
in GIMP, in the color space of the user's choice, is an entirely 
separate issue.


> Exporting to any particular bounded RGB gamut; as well as proofing
> whether colors are within a gamut should in no way be hampered.
>
> > * People who want or need a small gamut color space that is nonetheless
> > larger than the very small sRGB.
>
> The usefulness of the extended range in cyan/green; and how many
> perceptually discernable colors you gain compared to sRGB is
> questionable.

It might not be a lot of extra gamut, but every little bit helps.


> > A summary rejection of Adobe RGB (1998) ignores the needs and accustomed
> > workflows of the many, many photographers who work in the Adobe RGB (1998)
> > color space.
>
> Not having saddle adapters as mandatory attachment mechanisms for car
> seats ignores the needs and accustomed workflows of horse riders used
> to maintain and customize their leather saddles.

My apologies, I don't understand the analogy.


Elle