On 11/14/2014 02:15 AM, Øyvind Kolås wrote:
On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone
<ellest...@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

_______________________________________________
gimp-user-list mailing list
List address:    gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

Reply via email to