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

[Gez <listas ohweb com ar>]

El jue, 17-04-2014 a las 16:02 +0200, Øyvind Kolås escribió:
> 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.

It makes sense for lots of people's usual workflow. It's what people do
now with GIMP and other similar tools.
Now, I don't have anything against improved and simplified workflows if
they are transparent to users.
The unbounded gamut thing sounds great if it can be implemented without
breaking the way users work with their files.
And that's my concern (I think Elle's too).
For instance, in Elle's example -the yellow flower with hidden detail in
the blue channel- there's a valid and common use of extra gamut.
Pulling information of channels for creative or technical purposes
shouldn't be ruled out.
It's what artists do, not only for creative black and white, but for
pulling mattes for compositing, among other uses.
And that's just one example.

Our concern (here I'll speak for Elle too, I think she meant the same in
her observations) is that way too many things have to be accomodated to
work with the unbounded gamut model, both in the application and the
users workflow. And in some cases it is uncertain that they will work (I
cited the multiply/divide operations giving unusable results)

But if you can guarantee that it's not going to impact on users freedom
and expectations, I'll just STFU :-)

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

I think I understand the idea, and it seems solid... for sRGB, or for
images that don't have to go through heavy editing and compositing.

Elle and I have made some tests where the results of working in
unbounded sRGB are really different than doing the same in the original
colorspace (read colorspace here as primaries only, I'm leaving all the
trc conversions out for the sake of simplicity and going straight to the
point).
That seems to indicate that several operations have to be modified in
order to accomodate with working with unbounded values. And they are
operations that would work without modifications in a bounded
colorspace, even for HDR images.

In our conversation over IRC you stated that the same out-of-bounds
values you have in unbounded sRGB are also a problem in HDR files, but
that doesn't seem to be entirely correct.
It's true that HDR images can end up with negative and >1, but in those
images values above 1 NEVER mean out of gamut colors. It means the
saturated primary with more intensity, not for instance "redder than
red"
And those >1 values don't seem to be a problem for compositing or
editing.
Negative values, on the other hand, are always a problem. But in a
scene-referred linear light model, light intensity is supposed to go
between 0 and infinity, so it's quite safe to clip something that means
"negative light intensity" because it's nonsense.
(there are special cases, like the results of convolutions where
negative values are still a problem, but they have to be addressed in a
different way, as you said).

In the unbounded model, the unbounded values mean out of gamut values,
and I think (and the tests I did seem to confirm it) that many
operations that are designed to mimic how light works in reality will
struggle with those values, because they're not anymore counterparts of
light (i.e.: the RGB channels are no longer equivalent to 3 colored
lamps with variable intensity)

The math of compositing and color operations seems to have been created
around that idea, and using a different paradigm for the contents of thr
RGB channels probably requires to rethink an important part of those
operations.

The concern and the question is if it's worth it. It seems a titanic
effort for something that doesn't necessarily mean a huge benefit.

Anyway, it's my personal perception. Maybe I'm getting all this wrong
and my concerns are unfounded. I'm totally open to be proven wrong, it's
a good way to learn new things :-)


> While doing
> global overrides of some of the internal pixel formats that are
> absolutely colorimetrically defined would make it easy to misconfigure
> the color settings yielding surprising and inconsistent behavior.


That's true and I've witnessed that hundreds of times during my carreer
as a designer. Most of the graphic designers I know (who use Adobe)
don't know what to do with the color settings dialog and leave them
untouched, or in the worst cases touch it without knowing what they're
doing.
But you can't just assume that all users won't know what to do with
color profiles.
As I mentioned before in the recent softproofing thread, I'm all for
removing some confusing and error prone elements of the color managed
workflow, but that should result in something the allows a sane color
managed workflow where users have control, not a "transparent" thing
where you only select your output bounded color profile and nothing
else.


> > 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 to provide adequate headroom/footroom - though with a
> predominantely floating point based processing doing this might not be
> a huge win.

As a person whose work consists in sending files to offset print shops
weekly, I tend to agree that the AdobeRBG's gamut gain in green is
almost irrelevant, and the gain in cyans is marginal, considering the
gamut of the usual output colorspaces.
I don't think AdobeRGB is that important for general print, but it's
still widely used and some specific models of photographic printers seem
to be specially tailored towards the green and cyan extra gamut provided
by AdobeRGB.

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

I agree.

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

Heh, that's not a good argument for something that is more a PR issue
than a technical one. People use Adobe.
You can't use that argument in a world where people still uses toilet
paper :-)

Gez.