Re: [Gimp-user] Time to fork BABL and GEGL

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/14/2014 02:15 AM, Øyvind Kolås wrote:
> On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone
> <ellestone ninedegreesbelow com> wrote:
> > if the other babl/GEGL/GIMP developers really are in agreement with Jon
> > Nordby (the babl roadmap leaves room for differing interpretations), then
> > there is no reason whatsoever for further discussion of forking babl and
> > GEGL to benefit GIMP.
>
> Misinterpreting is your choice. You still seem to have little trust
> that babl/GEGL/GIMP developers have the interests of users/colors or
> the future of their software in mind.

Really there is only one developer who's current stance on unbounded 
sRGB seems a little unclear.

> babl/GEGL/GIMP developers have had rough consensus on this topic since
> march or april,

You are somewhat rewriting history:

In 2011 Kolås said:

"My stance is that the sliders on an operations should be predictable 
and always do the same thing for the colorimetrically absolute same 
color . . . . The RGB space defined by and used by babl uses the same 
primaries as sRGB" 
(http://article.gmane.org/gmane.comp.video.gimp.devel/19916)

In 2012 Kolås said:

"ICC profiles should only need to be involved upon loading files from 
disk and exporting to files used outside - internally it is up to 
GIMP/GEGL/babl to assign appropriate fully color managed color spaces to 
the raster storage of the buffers in the layers; for 8bpc precision this 
will be sRGB and for higher bitdepths this should be linear light/linear 
scRGB . . . . this differs from any assumptions that might have been in 
2.8 and before wrt color management and the ability to assign color 
profiles to images; I would not trust (and want GIMP to get rid of) any 
such things in the UI." 
(https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00261.html)

In March 2014 Kolås confirmed that images would be converted to 
unbounded sRGB before editing could begin 
(https://mail.gnome.org/archives/gimp-developer-list/2014-March/msg00086.html).

In April 2014 I asked for explicit confirmation that in GIMP 2.10 all 
images would be converted to unbounded sRGB before editing would begin 
("extended" and "unbounded" mean the same thing):

"[Q] Will the image be converted to extended sRGB before image editing 
can begin?
[A] Yes." 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00001.html)

In April 2014 two other GIMP users and myself started testing whether 
unbounded sRGB actually was a viable model for image editing, and I took 
on the task of posting our results to the GIMP developers mailing list.

Initially Kolås dismissed our results as involving extreme edits and/or 
colors that hardly ever showed up in real images. Then he decided that 
at some point in the future special treatment might be needed for some 
images, some of the time. The record is in the April and May GIMP 
developer's mailing list:

Some blend modes break in unbounded mode sRGB 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00049.html)

GIMP and Adobe RGB (1998) 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00094.html)

Attempt to summarize the discussion of my examples of what doesn't work 
in unbounded sRGB 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00102.html)

Drawing Rec 2020 gradients in the unbounded mode sRGB color space 
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00103.html)

Gamma slider adjustments don't work in unbounded mode sRGB
(https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00133.html)

Possible approach for some non-sRGB GEGL/GIMP color workflows 
(https://mail.gnome.org/archives/gimp-developer-list/2014-May/msg00059.html)

Then I gave up the discussion as a lost cause, until this article was 
posted to the web:

About Rendering Engines Colourspaces Agnosticism 
(http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb)

GIMP being extremely important free/libre editing software, it seemed 
worthwhile to start another discussion on the topic of unbounded sRGB:

Don't make an architectural mistake based on a groundless premise 
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00002.html)

Twice in subsequent discussion it seemed that at least some of the 
babl/GEGL/GIMP devs had given up on unbounded sRGB, but each time Kolås 
made it clear that Kolås hadn't given up on unbounded sRGB. Here's 
Kolås's last public statement on the topic of unbounded sRGB ("bablRGB" 
and "fixed linear RGB" both mean unbounded sRGB):

"the first thing we should do is to annotate all the operations which 
are broken when done with sRGB primaries, then we will be able to 
continue refactoring, profiling and optimizing; without breaking 
existing functionality/rendering. Not only in terms of making more 
operations request directly userRGB, but also doing things like make 
some linear operations accept any of userRGB or bablRGB (or other linear 
RGB). . . . Using a fixed linear RGB format instead of userRGB is what 
for some operations will provide the consistent results for the same 
property values / slider positions" 
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00096.html)

Contrary to Kolås's statement, there are no "broken" operations. Rather 
the unbounded sRGB architecture itself is broken and the desire for 
"consistent" slider results is directly contrary to the requirements for 
RGB image editing.

> and the roadmap is as detailed as it is not for the
> benefit of babl/GEGL developers but to contrast the endless and
> pointless email threads.

The babl roadmap doesn't rule out unbounded sRGB:

"Babl currently only supports formats using the sRGB primaries, quite a 
few editing operations including gamma adjustments and multiply 
compositing relies on the chromaticities of the space used, permitting 
at least linear formats with other chromaticities is highly desirable"

> If the hundreds of hours donated/devoted to
> the topic had been spent on actual development instead of disagreement
> about how the software should be developed, we would have a more
> capable stack already.

GIMP is too important to free/libre image editing to be left saddled 
with a hopelessly broken unbounded sRGB architecture that was based on 
the groundless premise that slider adjustments should always produce 
consistent results.

Development time spent on implementing unbounded sRGB would have been 
completely wasted time.

For the record, I'm 99.9999% sure that (most of, if not all) the 
babl/GEGL/GIMP devs have abandoned unbounded sRGB. Code speaks louder 
than words and I will be 100% convinced that unbounded sRGB has been 
abandoned when the appropriate babl format specifiers are written, and 
the requisite generalized or duplicate babl functions are made available 
for use in GEGL and GIMP 
(https://mail.gnome.org/archives/gimp-user-list/2014-November/msg00057.html).
> /pippin

Elle