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

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

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:

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]