On 11/14/2014 02:15 AM, Øyvind Kolås wrote:
On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone
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"
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."
In March 2014 Kolås confirmed that images would be converted to
unbounded sRGB before editing could begin
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
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
GIMP and Adobe RGB (1998)
Attempt to summarize the discussion of my examples of what doesn't work
in unbounded sRGB
Drawing Rec 2020 gradients in the unbounded mode sRGB color space
Gamma slider adjustments don't work in unbounded mode sRGB
Possible approach for some non-sRGB GEGL/GIMP color workflows
Then I gave up the discussion as a lost cause, until this article was
posted to the web:
About Rendering Engines Colourspaces Agnosticism
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
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"
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
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
gimp-user-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list