Sign up now! · Forgot password?
RSS/Atom feed identi.ca Twitter

Time to fork BABL and GEGL

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

72 of 72 messages available
Toggle history

Please log in to manage your subscriptions.

Time to fork BABL and GEGL billn 09 Nov 03:27
  Time to fork BABL and GEGL Gene Heskett 09 Nov 04:05
  Time to fork BABL and GEGL Alexandre Prokoudine 09 Nov 07:56
   Time to fork BABL and GEGL Elle Stone 09 Nov 12:23
    Time to fork BABL and GEGL billn 14 Nov 03:03
     Time to fork BABL and GEGL Alexandre Prokoudine 14 Nov 09:56
      Time to fork BABL and GEGL Michael Schumacher 14 Nov 10:11
      Time to fork BABL and GEGL Elle Stone 14 Nov 13:26
    Time to fork BABL and GEGL Øyvind Kolås 14 Nov 07:15
     Time to fork BABL and GEGL Elle Stone 14 Nov 13:26
      Time to fork BABL and GEGL Øyvind Kolås 14 Nov 14:04
       Time to fork BABL and GEGL Elle Stone 14 Nov 15:48
        Time to fork BABL and GEGL Øyvind Kolås 14 Nov 16:08
         Time to fork BABL and GEGL Elle Stone 14 Nov 16:24
          Time to fork BABL and GEGL Øyvind Kolås 14 Nov 16:47
           Time to fork BABL and GEGL Alexandre Prokoudine 14 Nov 17:01
            Time to fork BABL and GEGL Elle Stone 14 Nov 17:15
           Time to fork BABL and GEGL Elle Stone 15 Nov 20:00
           Time to fork BABL and GEGL Elle Stone 15 Nov 20:01
            Time to fork BABL and GEGL billn 16 Nov 00:05
             Time to fork BABL and GEGL Alexandre Prokoudine 16 Nov 00:31
              Time to fork BABL and GEGL Michael Schumacher 16 Nov 00:47
            Time to fork BABL and GEGL Øyvind Kolås 16 Nov 01:20
             Time to fork BABL and GEGL Elle Stone 16 Nov 21:01
              Time to fork BABL and GEGL Øyvind Kolås 16 Nov 22:18
               Time to fork BABL and GEGL Elle Stone 17 Nov 14:43
                Time to fork BABL and GEGL Simon Budig 17 Nov 15:46
                 Time to fork BABL and GEGL Elle Stone 17 Nov 21:03
                  Time to fork BABL and GEGL Mikael Magnusson 17 Nov 22:41
                   Time to fork BABL and GEGL Elle Stone 17 Nov 23:52
                    Time to fork BABL and GEGL Ed . 18 Nov 00:32
                     Time to fork BABL and GEGL Gez 18 Nov 01:20
                     Time to fork BABL and GEGL Elle Stone 18 Nov 10:17
                      Time to fork BABL and GEGL Ed . 18 Nov 15:27
                       Time to fork BABL and GEGL Simos Xenitellis 18 Nov 15:50
                       Time to fork BABL and GEGL Alexandre Prokoudine 18 Nov 15:55
                        Time to fork BABL and GEGL Simon Budig 18 Nov 16:15
                   Time to fork BABL and GEGL Gez 18 Nov 01:48
                    Time to fork BABL and GEGL Michael Henning 18 Nov 02:19
                     Time to fork BABL and GEGL Gez 18 Nov 04:39
                      Time to fork BABL and GEGL Michael Henning 18 Nov 08:05
                       Time to fork BABL and GEGL Elle Stone 18 Nov 16:00
                        Time to fork BABL and GEGL Elle Stone 18 Nov 16:05
                        Time to fork BABL and GEGL Alexandre Prokoudine 18 Nov 16:16
                         Time to fork BABL and GEGL Elle Stone 18 Nov 17:39
                        Time to fork BABL and GEGL Elle Stone 19 Nov 19:31
                         Time to fork BABL and GEGL Øyvind Kolås 19 Nov 20:27
                          Time to fork BABL and GEGL Elle Stone 19 Nov 21:28
                           Time to fork BABL and GEGL Øyvind Kolås 19 Nov 21:47
                            Time to fork BABL and GEGL Elle Stone 19 Nov 22:57
                             Time to fork BABL and GEGL Simon Budig 19 Nov 23:13
                              Time to fork BABL and GEGL Simon Budig 20 Nov 03:47
                               Time to fork BABL and GEGL Gary Aitken 20 Nov 08:45
                               Time to fork BABL and GEGL Elle Stone 20 Nov 09:42
                                Time to fork BABL and GEGL Mikael Magnusson 20 Nov 10:13
                                 Time to fork BABL and GEGL Elle Stone 20 Nov 10:19
                                Time to fork BABL and GEGL Øyvind Kolås 20 Nov 10:17
                                 Time to fork BABL and GEGL Elle Stone 20 Nov 11:21
                              Time to fork BABL and GEGL Elle Stone 20 Nov 09:30
                             Time to fork BABL and GEGL Jon Nordby 19 Nov 23:20
                              Time to fork BABL and GEGL Elle Stone 20 Nov 09:34
                               Time to fork BABL and GEGL Elle Stone 20 Nov 11:53
                                Time to fork BABL and GEGL Elle Stone 21 Nov 14:05
                                 Time to fork BABL and GEGL Alexandre Prokoudine 21 Nov 14:06
                                 Time to fork BABL and GEGL Øyvind Kolås 21 Nov 14:43
                                  Time to fork BABL and GEGL Elle Stone 21 Nov 14:55
                  Time to fork BABL and GEGL Simon Budig 17 Nov 23:56
                   Time to fork BABL and GEGL Øyvind Kolås 18 Nov 00:08
                   Time to fork BABL and GEGL Elle Stone 18 Nov 10:16
                   Time to fork BABL and GEGL Saul Goode 19 Nov 10:49
        Time to fork BABL and GEGL Simon Budig 14 Nov 16:21
         Time to fork BABL and GEGL Elle Stone 14 Nov 16:26
2014-11-09 03:27:45 UTC (over 3 years ago)
postings
52
contact
Send private message

Time to fork BABL and GEGL

Time to fork off BABL and GEGL. Forking was good for Openoffice. LIbreoffice is kicking tail. Developers who want to turn out a good product in a timely manner and other programmers who want to wait 3-5 years for small improvements. LOL

Gene Heskett
2014-11-09 04:05:30 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Saturday 08 November 2014 22:27:45 billn did opine And Gene did reply:

Time to fork off BABL and GEGL. Forking was good for Openoffice. LIbreoffice is kicking tail. Developers who want to turn out a good product in a timely manner and other programmers who want to wait 3-5 years for small improvements. LOL

Thats a yes and no situation. None of the artwork examples that many megabytes of that come with OO, do not come with LO for copyright reasons.

And despite that I still like LO better, I have now tried to dl the latest update 7 times, 6 of those made it to something north of 208 megs and stalled, and once only to about 30 megs. I have no clue how many megs the tarball actually is, oly that if I rename it so a tar session can unpack it, the tarball is incomplete.

I am tempted to think that it stalls if you do not make a donation from that same screen, and I am not the least allergic to supporting the project, but I don't buy a 3 legged pig in a poke.

Cheers, Gene Heskett

"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
Alexandre Prokoudine
2014-11-09 07:56:43 UTC (over 3 years ago)

Time to fork BABL and GEGL

09 нояб. 2014 г. 6:28 пользователь "billn" написал:

Time to fork off BABL and GEGL. Forking was good for Openoffice.

LIbreoffice is

kicking tail. Developers who want to turn out a good product in a timely

manner

and other programmers who want to wait 3-5 years for small improvements.

LOL

I'm not sure if it was meant as sarcasm or if it was serious. However, if you are not personally prepared to maintain a develop fork, you might reconsider publicly suggesting something that makes sense so little that you'd need a microscope to expertly deal with it.

The topic of forking the libraries was born out of miscommunication. Could we please finally bury this?

Alex

Elle Stone
2014-11-09 12:23:43 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/09/2014 02:56 AM, Alexandre Prokoudine wrote:

09 нояб. 2014 г. 6:28 пользователь "billn" написал:

Time to fork off BABL and GEGL. Forking was good for Openoffice.

LIbreoffice is

kicking tail. Developers who want to turn out a good product in a timely

manner

and other programmers who want to wait 3-5 years for small improvements.

LOL

I'm not sure if it was meant as sarcasm or if it was serious. However, if you are not personally prepared to maintain a develop fork, you might reconsider publicly suggesting something that makes sense so little that you'd need a microscope to expertly deal with it.

The topic of forking the libraries was born out of miscommunication. Could we please finally bury this?

I agree with Alexandre. If I really do understand what Jon Nordby is saying (see
https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00018.html and
https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00023.html), and 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.

2014-11-14 03:03:27 UTC (over 3 years ago)
postings
52
contact
Send private message

Time to fork BABL and GEGL

BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools..

I agree with Alexandre. If I really do understand what Jon Nordby is saying (see
https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00018.html and
https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00023.html), and 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.

Øyvind Kolås
2014-11-14 07:15:47 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone 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.

babl/GEGL/GIMP developers have had rough consensus on this topic since march or april, 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. 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.

/pippin

Alexandre Prokoudine
2014-11-14 09:56:22 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Fri, Nov 14, 2014 at 6:03 AM, billn wrote:

BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools.

Are you suggesting that relicensing babl would somehow magically right all wrongs? :) How?

Alex

Michael Schumacher
2014-11-14 10:11:11 UTC (over 3 years ago)

Time to fork BABL and GEGL

Von: "Alexandre Prokoudine"

On Fri, Nov 14, 2014 at 6:03 AM, billn wrote:

BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools.

Are you suggesting that relicensing babl would somehow magically right all wrongs? :) How?

Do not feed the troll.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
Elle Stone
2014-11-14 13:26:14 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/14/2014 02:15 AM, Øyvind Kolås wrote:

On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone 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

Elle Stone
2014-11-14 13:26:34 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/14/2014 04:56 AM, Alexandre Prokoudine wrote:

On Fri, Nov 14, 2014 at 6:03 AM, billn wrote:

BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools.

Are you suggesting that relicensing babl would somehow magically right all wrongs? :) How?

I *think* Bill N might think that forking babl would mean that GIMP development could switch to a "release early and often" approach to future development. I think that's the difference between OpenOffice and LibreOffice that he's pointed to.

People who don't make a habit of reading the babl/GEGL/GIMP git logs on a regular basis might not realize what a huge amount of coding effort has gone into the conversion to a geglified GIMP. It's not a matter of incremental improvements.

Elle

Øyvind Kolås
2014-11-14 14:04:55 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Fri, Nov 14, 2014 at 1:26 PM, Elle Stone > Really there is only one developer who's current stance on unbounded sRGB

seems a little unclear.

Or there is one time-thief that continues to not understand what a PCS is in a color management system, what implementation details mean; which is allergic to implementation details involving anything relating to sRGB; that continues to argue over her own misunderstandings of the architecture. The writeup in the babl roadmap document is a summary of the ideas that have been around since LGM in Leipzig; which was in the beginning of April this year. You convinced us that we had to care about RGB spaces beyond sRGB; and we decided to incorporate that in the architecture with a concept of a "target-space"; this was in my eyes thus far your thus far last positive contribution.

I have spent hundreds of hours more on babl/GEGL this year than I intended, most of them on unproductive arguments on mailinglists, a medium I not well suited for clearing up misunderstandings but you refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC.

I wrote the babl roadmap when it became clear that playing in your preferred medium, on the mailinglist, answering your questions was more conductive to deepen misunderstandings than clear them up. Like the continued refusal to understand that converting to unbounded linear sRGB on import to the system would be an implementation detail and not neccesarily mean that any processing would necessarily happen in that format - as well as broader principles of software engineering and how one keeps working code working.

/pippin

Elle Stone
2014-11-14 15:48:42 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/14/2014 09:04 AM, Øyvind Kolås wrote:

I have spent hundreds of hours more on babl/GEGL this year than I intended, most of them on unproductive arguments on mailinglists, a medium I not well suited for clearing up misunderstandings

I agree with you 100% that you shouldn't waste your time responding to mailing list discussions. Personally I would very much prefer that you use your time to:

* Write the requisite babl format specifiers for allowing GEGL and GIMP code to be modified so functions can use Y and XYZ values from the user's chosen RGB working space, instead of using hard-coded sRGB values.

* Write the requisite generalized or additional babl functions so that when the user draws on a mask or uses a grayscale image as a mask, the mask is drawn using the correct Y values from the user's chosen RGB working space, instead of using hard-coded sRGB Y values.

* And maybe fix the babl "conversion to LAB" code that still uses unadapted D65 sRGB values instead of the D50-adapted values suitable for an ICC profile color-managed workflow. The current code produces wrong results for ICC profile color-managed sRGB images, and even more so for images in other RGB working spaces.

However, I do understand that proper ICC profile color management isn't a high priority for GIMP 2.10. So the hard-coded sRGB values might still be in the code base when GIMP 2.10 is released, which would mean GIMP 2.10 would produce incorrect results for some operations, for images that aren't sRGB images.

but you
refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC.

As you well know, I did try discussing unbounded sRGB with you on IRC. On IRC you felt free to issue personal insults. And you wasted time eliciting general agreement from people who learned everything they know about "color management" from you.

I wrote the babl roadmap when it became clear that playing in your preferred medium, on the mailinglist, answering your questions was more conductive to deepen misunderstandings than clear them up. Like the continued refusal to understand that converting to unbounded linear sRGB on import to the system would be an implementation detail and not neccesarily mean that any processing would necessarily happen in that format -

STILL you want to convert to unbounded sRGB upon opening an image? STILL?? Why???? What is this "implementation detail" supposed to accomplish?

In case you hadn't noticed, I had already ceased discussing unbounded sRGB, on the apparently quite mistaken assumption that the unbounded sRGB architecture had actually been abandoned.

In an ICC profile color-managed workflow:

* sRGB is just another RGB working space. * sRGB doesn't require special treatment, being handled just fine by generalized code that retrieves the user's chosen RGB working space's Y and XYZ values.
* Developers need to respect the user's RGB data. There is *never* any justification for forcibly convert the user's RGB data to an RGB working space not of the user's choosing.

as well as broader principles of software engineering and how one keeps working code working.

Nothing in the current GIMP code base depends on unbounded sRGB. No GIMP functionality will be broken by not writing new code that will convert the user's image to unbounded sRGB.

If you insist on writing special "sRGB only" code (unbounded or otherwise), at least give the user the option to opt out of using such code, even for sRGB images.

/pippin

Elle

Øyvind Kolås
2014-11-14 16:08:00 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Fri, Nov 14, 2014 at 3:48 PM, Elle Stone >> but you

refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC.

As you well know, I did try discussing unbounded sRGB with you on IRC. On IRC you felt free to issue personal insults. And you wasted time eliciting general agreement from people who learned everything they know about "color management" from you.

If calling the examples you used for "corner cases", and that one can construct scenes favoring different RGB spaces for orthogonality between channels - not only the sensor space - a personal insult; I call it being direct.

/pippin

Simon Budig
2014-11-14 16:21:13 UTC (over 3 years ago)

Time to fork BABL and GEGL

Hi Pippin, Hi Elle.

I know that i am not really a neutral party in this dispute, but I'll try anyways?

WILL YOU TWO PLEASE STOP FIGHTING?

Neither is Elle in the position to tell pippin what he is supposed to work on, nor is pippin right when he holds Elle responsible for the time he decided to "waste" in this discussion.

Elle is entitled to a "told you so" when "we" claim this feature to be done and she can figure out from the "outer" workflow if internal conversions happened or not.

Sheesh.

Bye, Simon

simon@budig.de              http://simon.budig.de/
Elle Stone
2014-11-14 16:24:45 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/14/2014 11:08 AM, Øyvind Kolås wrote:

On Fri, Nov 14, 2014 at 3:48 PM, Elle Stone >> but you

refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC.

As you well know, I did try discussing unbounded sRGB with you on IRC. On IRC you felt free to issue personal insults. And you wasted time eliciting general agreement from people who learned everything they know about "color management" from you.

If calling the examples you used for "corner cases", and that one can construct scenes favoring different RGB spaces for orthogonality between channels - not only the sensor space - a personal insult; I call it being direct.

/pippin

My apologies, I don't understand what you are trying to say. Can you give links to specific mailing list threads? Are you perhaps again saying that my yellow flower image is a corner case and therefore it's OK to write an image editor that makes it literally impossible for me to perform my envisioned conversion to black and white?

As an aside, insults are things like:

* "backseat driver"

* "half-knowledgeable filibusterer" (I'm only guessing that was directed at me; perhaps I'm wrong)

* suggesting on IRC that I'm "insulting GIMP" (which I have never done, GIMP is my favorite RGB image editor) when really I'm questioning your understanding of the requirements for proper RGB image editing

* suggesting that because I agree that you are intelligent (obviously you are), therefore I should stop trying to educate you about where your color management theories took a wrong turn and are threatening to take GIMP with them.

Elle Stone
2014-11-14 16:26:33 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/14/2014 11:21 AM, Simon Budig wrote:

Hi Pippin, Hi Elle.

I know that i am not really a neutral party in this dispute, but I'll try anyways?

WILL YOU TWO PLEASE STOP FIGHTING?

Neither is Elle in the position to tell pippin what he is supposed to work on, nor is pippin right when he holds Elle responsible for the time he decided to "waste" in this discussion.

Elle is entitled to a "told you so" when "we" claim this feature to be done and she can figure out from the "outer" workflow if internal conversions happened or not.

Sheesh.

Bye, Simon

+1

Elle

Øyvind Kolås
2014-11-14 16:47:35 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Fri, Nov 14, 2014 at 4:24 PM, Elle Stone wrote:

My apologies, I don't understand what you are trying to say. Can you give links to specific mailing list threads? Are you perhaps again saying that my yellow flower image is a corner case and therefore it's OK to write an image editor that makes it literally impossible for me to perform my envisioned conversion to black and white?

I was saying that one can construct a scene, that photographed with your camera, would yield the type of desired black and white - when done in sRGB or some other non sensor RGB space. So yes; for the purposes of black and white conversion and using a single channel for it - I still call that image a corner case.

* "backseat driver"

* "half-knowledgeable filibusterer" (I'm only guessing that was directed at me; perhaps I'm wrong)

* suggesting on IRC that I'm "insulting GIMP" (which I have never done, GIMP is my favorite RGB image editor) when really I'm questioning your understanding of the requirements for proper RGB image editing

* suggesting that because I agree that you are intelligent (obviously you are), therefore I should stop trying to educate you about where your color management theories took a wrong turn and are threatening to take GIMP with them.

You are quoting later venting of frustration with your later walls of text on the mailinglists questioning and demanding answers for every single little detail before details even exist. One of your quotes isn't even from IRC; and guess what, if you were on IRC I would have asked you questions there instead of venting frustration about your mailinglist posts.

I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account.

/pippin

Alexandre Prokoudine
2014-11-14 17:01:48 UTC (over 3 years ago)

Time to fork BABL and GEGL

14 нояб. 2014 г. 19:47 пользователь "Øyvind Kolås" написал:

You are quoting later venting of frustration with your later walls of text on the mailinglists questioning and demanding answers for every single little detail before details even exist.

Øyvind, having a last say in every dispute typically makes one look like a jerk. I am a living proof of that.

Elle, we do invite you to attend Libre Graphics Meeting 2015 in Toronto, April 29 to May 2. Travel expenses will be covered.

Alex

Elle Stone
2014-11-14 17:15:28 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/14/2014 12:01 PM, Alexandre Prokoudine wrote:

14 нояб. 2014 г. 19:47 пользователь "Øyvind Kolås" написал:

You are quoting later venting of frustration with your later walls of text on the mailinglists questioning and demanding answers for every single little detail before details even exist.

Øyvind, having a last say in every dispute typically makes one look like a jerk. I am a living proof of that.

I don't know as Pippin intended to have the last say. I replied to Pippin's next-to-last post about a half-minute before Simon's very wise post arrived in my inbox. So the timestamps are out of order. Pippin likewise may have hit the send button before receiving Simon's post.

Elle, we do invite you to attend Libre Graphics Meeting 2015 in Toronto, April 29 to May 2. Travel expenses will be covered.

Alex, that is very kind. If at all possible I will atttend. Toronto is easier than Germany. But other obligations unfortunately make travelling even to Toronto a bit difficult.

Alex
_______________________________________________ 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

Elle Stone
2014-11-15 20:00:51 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/14/2014 12:01 PM, Alexandre Prokoudine wrote:

Øyvind, having a last say in every dispute typically makes one look like a jerk. I am a living proof of that.

My apologies to Simon and Alex for continuing this discussion, and yes I guess I'll be "the jerk with the last word" unless Pippin wants to respond.

On 11/14/2014 11:47 AM, Øyvind Kolås wrote:

I was saying that one can construct a scene, that photographed with your camera, would yield the type of desired black and white - when done in sRGB or some other non sensor RGB space. So yes; for the purposes of black and white conversion and using a single channel for it - I still call that image a corner case.

I have no idea what Pippin means by "one can construct a scene, that photographed with your camera, would yield the type of desired black and white - when done in sRGB or some other non sensor RGB space." If someone can help me out here, I'd be grateful.

In the meantime, as a note to Pippin, it sort of sounds like you expect photographers to change their workflow and their way of taking pictures to suit your unbounded sRGB architecture.

The yellow flower in question is long dead. So if there ever was a possibility of reshooting the scene in a way that would make the blue channel information available for use in the sRGB color space, that possibility is gone.

The flower's blue channel has interesting detail that is missing in the red and green channels. I used the blue channel as a blending layer over a straight luminance-based conversion to black and white. Here's a link to my envisioned black and white conversion:

http://ninedegreesbelow.com/gimpgit/gimp-srgb/channel-mix-blend/flower-blue-channel-over-luminance.jpg

This article shows what happened when I tried to do the envisioned conversion to black and white in the unbounded sRGB color space:

Channel blending when converting to black and white can fail completely in the unbounded sRGB color space
(http://ninedegreesbelow.com/photography/unbounded-srgb-channel-blend-convert-black-white.html)

Frankly I am appalled that Pippin says my yellow flower image represents a "corner case". How many of *your* images will he dismiss as corner cases?

Elle

Elle Stone
2014-11-15 20:01:06 UTC (over 3 years ago)

Time to fork BABL and GEGL

This really is my last post on unbounded sRGB unless someone has a specific question to ask.

On 11/14/2014 11:47 AM, Øyvind Kolås wrote:

I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account.

I think it's important to clarify some of Pippin's misunderstandings that are betrayed in the above quote:

1. Multiply and gamma slider adjustments are both highly chromaticity dependent editing operations. What Kolås fails to acknowledge, and maybe doesn't even understand, is that this is true regardless of whether the RGB channel values are *in* or *out* of gamut with respect to the bounded sRGB color space.

2. Given that multiply and gamma slider adjustments produce different results in different RGB working spaces, only the *artist* has the right to decide which results are better. Developers aren't in a position to make this decision on behalf of users.

3. The fact that multiplying and making gamma slider adjustments on out of gamut channel values produce absolutely *meaningless* results is just icing on the badly baked cake that is unbounded sRGB. The artist's control over her own RGB data is already removed as soon as her RGB data is converted to unbounded sRGB without her consent.

4. The list of chromaticity dependent editing operations is much longer than just multiply and gamma slider adjustments:

* For editing performed on more or less perceptually uniform RGB data, the list includes essentially *all* editing operations.

* For editing performed on linear gamma RGB data, the list includes at least the following operations (I haven't checked every single editing operation made available through the GIMP UI):

Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL
Colors/Alien Map RGB
Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' "enhance green" formula) Colors/Desaturate average
Colors/Desaturate lightness Colors/Mono Mixer (except straight Luminosity-based B&W conversion) Colors/Posterize
Colors/Threshold
Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels "Auto Pick" (used for white balancing images) Filters/Artistic/Cartoon (this uses hard-coded Y values) Filters/Edge Detect/Sobel
Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise
Filters/Noise/RGB Noise
Filters/Artistic/Soft glow
Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn
Layer blend Mode/Color
Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide
Layer blend Mode/Dodge
Layer blend Mode/Hard light Layer blend Mode/Hue
Layer blend Mode/Lighten only Layer blend Mode/Multiply
Layer blend Mode/Overlay
Layer blend Mode/Screen
Layer blend Mode/Saturation Layer blend Mode/Value
Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value.

In other words, *most* editing operations are chromaticity dependent. This means the *artist*, not the developer, is the only person who should choose the RGB working space.

5. Putting aside color gamut limitations, the editing operations that are chromaticity *in*dependent already produce exactly the same results (same XYZ colors) in all RGB working spaces. So for chromaticity *in*dependent editing operations, there is no point whatsoever in forcing these operations to be performed in the unbounded sRGB color space. But there are two serious *dis*advantages:

1. Conversions between color spaces necessarily involve floating point rounding errors, and rounding errors will accumulate over time as the RGB channel data is needlessly converted back and forth between the user's chosen RGB working space and unbounded sRGB.

2. The user is entirely at the mercy of developer decisions as to which operations will be done in the user's chosen RGB working space and which will be done in the unbounded sRGB color space.

This article provides an overview of problems with unbounded sRGB image editing: Using unbounded sRGB as a universal color space for image editing is a really bad idea
(http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html)

If you find the article to be too technical, looking at the pictures should be enough to let you see what the problems with unbounded sRGB really are. If you follow the links in the article, again you don't really need to read the text, just look at the pictures and you will see that unbounded sRGB image editing is a really, really bad idea.

Best regards, Elle Stone

http://ninedegreesbelow.com
Color management and free/libre photography
2014-11-16 00:05:17 UTC (over 3 years ago)
postings
52
contact
Send private message

Time to fork BABL and GEGL

My way or the highway developers. How many would love to fork? LIbreoffice and Ubuntu folks may help with funds needed to move Gimp to the next level.

This really is my last post on unbounded sRGB unless someone has a specific question to ask.
I think it's important to clarify some of Pippin's misunderstandings that are betrayed in the above quote:

1. Multiply and gamma slider adjustments are both highly chromaticity dependent editing operations. What Kolås fails to acknowledge, and maybe
doesn't even understand, is that this is true regardless of whether the
RGB channel values are *in* or *out* of gamut with respect to the bounded sRGB color space.

2. Given that multiply and gamma slider adjustments produce different results in different RGB working spaces, only the *artist* has the right
to decide which results are better. Developers aren't in a position to make this decision on behalf of users.

3. The fact that multiplying and making gamma slider adjustments on out
of gamut channel values produce absolutely *meaningless* results is just
icing on the badly baked cake that is unbounded sRGB. The artist's control over her own RGB data is already removed as soon as her RGB data
is converted to unbounded sRGB without her consent.

4. The list of chromaticity dependent editing operations is much longer
than just multiply and gamma slider adjustments:

* For editing performed on more or less perceptually uniform RGB data, the list includes essentially *all* editing operations.

* For editing performed on linear gamma RGB data, the list includes
at least the following operations (I haven't checked every single editing operation made available through the GIMP UI):

Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL
Colors/Alien Map RGB
Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' "enhance green" formula) Colors/Desaturate average
Colors/Desaturate lightness
Colors/Mono Mixer (except straight Luminosity-based B&W conversion)
Colors/Posterize
Colors/Threshold
Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels "Auto Pick" (used for white balancing images) Filters/Artistic/Cartoon (this uses hard-coded Y values) Filters/Edge Detect/Sobel
Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise
Filters/Noise/RGB Noise
Filters/Artistic/Soft glow
Filters/Artistic/Vignette (any color except gray, white, black)
Layer blend Mode/Burn
Layer blend Mode/Color
Layer blend Mode/Darken only Layer blend Mode/Difference
Layer blend Mode/Divide
Layer blend Mode/Dodge
Layer blend Mode/Hard light
Layer blend Mode/Hue
Layer blend Mode/Lighten only Layer blend Mode/Multiply
Layer blend Mode/Overlay
Layer blend Mode/Screen
Layer blend Mode/Saturation
Layer blend Mode/Value
Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value.

In other words, *most* editing operations are chromaticity dependent. This means the *artist*, not the developer, is the only person who should choose the RGB working space.

5. Putting aside color gamut limitations, the editing operations that are chromaticity *in*dependent already produce exactly the same results
(same XYZ colors) in all RGB working spaces. So for chromaticity *in*dependent editing operations, there is no point whatsoever in forcing these operations to be performed in the unbounded sRGB color space. But there are two serious *dis*advantages:

1. Conversions between color spaces necessarily involve floating point rounding errors, and rounding errors will accumulate over time as
the RGB channel data is needlessly converted back and forth between the
user's chosen RGB working space and unbounded sRGB.

2. The user is entirely at the mercy of developer decisions as to which operations will be done in the user's chosen RGB working space and
which will be done in the unbounded sRGB color space.

This article provides an overview of problems with unbounded sRGB image
editing: Using unbounded sRGB as a universal color space for image editing is a really bad idea
(http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html)

If you find the article to be too technical, looking at the pictures should be enough to let you see what the problems with unbounded sRGB really are. If you follow the links in the article, again you don't really need to read the text, just look at the pictures and you will see
that unbounded sRGB image editing is a really, really bad idea.

Best regards, Elle Stone

Alexandre Prokoudine
2014-11-16 00:31:29 UTC (over 3 years ago)

Time to fork BABL and GEGL

16 нояб. 2014 г. 3:05 пользователь "billn" написал:

My way or the highway developers. How many would love to fork?

LIbreoffice and

Ubuntu folks may help with funds needed to move Gimp to the next level.

This is free software, so you are entitled to forking it, even if you don't understand why you would be doing that, exactly. And you do not understand that judging by how easily you dismiss both sides of the argument telling you there is no controversy, just misunderstanding.

I strongly suggest that you start your own mailing list to discuss all these forks you've been talkibg about. Your further emails here will be regrettably moderated.

Alex

Michael Schumacher
2014-11-16 00:47:26 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 16.11.2014 01:31, Alexandre Prokoudine wrote:

16 нояб. 2014 г. 3:05 пользователь "billn" написал:

My way or the highway developers.

Your further emails here will be regrettably moderated.

[x] done

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD
Øyvind Kolås
2014-11-16 01:20:46 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone wrote:

This really is my last post on unbounded sRGB unless someone has a specific question to ask.

On 11/14/2014 11:47 AM, Øyvind Kolås wrote:

I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account.

I think it's important to clarify some of Pippin's misunderstandings that are betrayed in the above quote:

1. Multiply and gamma slider adjustments are both highly chromaticity dependent editing operations. What Kolås fails to acknowledge, and maybe doesn't even understand, is that this is true regardless of whether the RGB channel values are *in* or *out* of gamut with respect to the bounded sRGB color space.

The multiply compositing op; doesn't really have any sliders, and gamma adjustments are among the things that definetely would not end up using bablRGB; regardless of how far we get in specifying other working spaces.

2. Given that multiply and gamma slider adjustments produce different results in different RGB working spaces, only the *artist* has the right to decide which results are better. Developers aren't in a position to make this decision on behalf of users.

3. The fact that multiplying and making gamma slider adjustments on out of gamut channel values produce absolutely *meaningless* results is just icing on the badly baked cake that is unbounded sRGB. The artist's control over her own RGB data is already removed as soon as her RGB data is converted to unbounded sRGB without her consent.

4. The list of chromaticity dependent editing operations is much longer than just multiply and gamma slider adjustments:

* For editing performed on more or less perceptually uniform RGB data, the list includes essentially *all* editing operations.

* For editing performed on linear gamma RGB data, the list includes at least the following operations (I haven't checked every single editing operation made available through the GIMP UI):

Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL
Colors/Alien Map RGB
Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' "enhance green" formula) Colors/Desaturate average
Colors/Desaturate lightness
Colors/Mono Mixer (except straight Luminosity-based B&W conversion) Colors/Posterize
Colors/Threshold
Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels "Auto Pick" (used for white balancing images) Filters/Artistic/Cartoon (this uses hard-coded Y values) Filters/Edge Detect/Sobel
Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise
Filters/Noise/RGB Noise
Filters/Artistic/Soft glow
Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn
Layer blend Mode/Color
Layer blend Mode/Darken only Layer blend Mode/Difference
Layer blend Mode/Divide
Layer blend Mode/Dodge
Layer blend Mode/Hard light
Layer blend Mode/Hue
Layer blend Mode/Lighten only Layer blend Mode/Multiply
Layer blend Mode/Overlay
Layer blend Mode/Screen
Layer blend Mode/Saturation
Layer blend Mode/Value
Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value.

In other words, *most* editing operations are chromaticity dependent. This means the *artist*, not the developer, is the only person who should choose the RGB working space.

5. Putting aside color gamut limitations, the editing operations that are chromaticity *in*dependent already produce exactly the same results (same XYZ colors) in all RGB working spaces. So for chromaticity *in*dependent editing operations, there is no point whatsoever in forcing these operations to be performed in the unbounded sRGB color space. But there are two serious *dis*advantages:

1. Conversions between color spaces necessarily involve floating point rounding errors, and rounding errors will accumulate over time as the RGB channel data is needlessly converted back and forth between the user's chosen RGB working space and unbounded sRGB.

2. The user is entirely at the mercy of developer decisions as to which operations will be done in the user's chosen RGB working space and which will be done in the unbounded sRGB color space.

This article provides an overview of problems with unbounded sRGB image editing: Using unbounded sRGB as a universal color space for image editing is a really bad idea
(http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html)

If you find the article to be too technical, looking at the pictures should be enough to let you see what the problems with unbounded sRGB really are. If you follow the links in the article, again you don't really need to read the text, just look at the pictures and you will see that unbounded sRGB image editing is a really, really bad idea.

Best regards, Elle Stone

Is there anything above that hasn't already been stated a couple of times?

/pippin

Elle Stone
2014-11-16 21:01:28 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/15/2014 08:20 PM, Øyvind Kolås wrote:

On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone wrote:

This really is my last post on unbounded sRGB unless someone has a specific question to ask.

Well, I think a question was asked.

On 11/14/2014 11:47 AM, Øyvind Kolås wrote:

I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account.

I think it's important to clarify some of Pippin's misunderstandings that are betrayed in the above quote:

1. Multiply and gamma slider adjustments are both highly chromaticity dependent editing operations. What Kolås fails to acknowledge, and maybe doesn't even understand, is that this is true regardless of whether the RGB channel values are *in* or *out* of gamut with respect to the bounded sRGB color space.

The multiply compositing op; doesn't really have any sliders,

I don't think you intended to imply that I think the Multiply layer blend mode ("compositing op") has a slider. So I'll assume you are rightly pointing to an ambiguity in how I phrased the sentence. I should have said something like this: "Multiply and also Levels gamma slider adjustments".

and
gamma adjustments are among the things that definetely would not end up using bablRGB; regardless of how far we get in specifying other working spaces.

I'm going to ask you a question. Please don't take the question the wrong way. I'm trying to establish some common ground for communication.

Here's some background to the question:

There are four basic mathematical operations that can be performed on the pixels in an RGB image: add and subtract, and multiply and divide.

Add and subtract are inverses, and multiply and divide are inverses, so really the four basic operations reduce to two: add and multiply.

Here's the question:

Do you understand that when I say that Multiply is a chromaticity-dependent editing operation, I don't just mean the Multiply layer blend mode? that in fact *all* editing operations that use multiplication or division are chromaticity dependent, regardless of whether the colors are *in* gamut or *out* of gamut with respect to the very small bounded sRGB color gamut?

The exception to "all", of course, is when multiplying or dividing by black, gray, or white.

See:
1.
http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb 2.
http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html 3.
http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html

4. The list of chromaticity dependent editing operations is much longer than just multiply and gamma slider adjustments:

* For editing performed on more or less perceptually uniform RGB data, the list includes essentially *all* editing operations.

* For editing performed on linear gamma RGB data, the list includes at least the following operations (I haven't checked every single editing operation made available through the GIMP UI):

Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL
Colors/Alien Map RGB
Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' "enhance green" formula) Colors/Desaturate average
Colors/Desaturate lightness Colors/Mono Mixer (except straight Luminosity-based B&W conversion) Colors/Posterize
Colors/Threshold
Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels "Auto Pick" (used for white balancing images) Filters/Artistic/Cartoon (this uses hard-coded Y values) Filters/Edge Detect/Sobel
Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise
Filters/Noise/RGB Noise
Filters/Artistic/Soft glow
Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn
Layer blend Mode/Color
Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide
Layer blend Mode/Dodge
Layer blend Mode/Hard light Layer blend Mode/Hue
Layer blend Mode/Lighten only Layer blend Mode/Multiply
Layer blend Mode/Overlay
Layer blend Mode/Screen
Layer blend Mode/Saturation Layer blend Mode/Value
Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value.

In other words, *most* editing operations are chromaticity dependent. This means the *artist*, not the developer, is the only person who should choose the RGB working space.

Is there anything above that hasn't already been stated a couple of times?

You are correct as far as what's been said on the developers lists. I was trying to summarize the information for GIMP users.

Somewhat switching gears, the revised babl roadmap (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says:

"Once a format has been resolved using babl_format(babl, "bar:RGBA float") the returned pointer would refer to the babl context that looked up "bar"'s definition of bar. This . . . allows rigging up a situation where the user has control over the RGB space used for chromaticity dependent operations."

In light of the revised roadmap and the above list of chromaticity dependent editing operations, I have two more questions. Again, I'm trying to establish common ground for communication, or at least clarify where we disagree.

1. Do you agree or disagree that for *all* chromaticity dependent editing operations, the *user* should be in control of which RGB chromaticities are used to perform the operation?

2. Do you agree or disagree that for chromaticity *in*depedent editing operations (for example, and assuming linearized RGB: adding, scaling, gaussian blur, etc), the same results (same XYZ values) are obtained whether the operation is done in the user's chosen RGB working space or in unbounded sRGB?

/pippin

Elle

Øyvind Kolås
2014-11-16 22:18:20 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone wrote:

Do you understand that when I say that Multiply is a chromaticity-dependent editing operation, I don't just mean the Multiply layer blend mode? that in fact *all* editing operations that use multiplication or division are chromaticity dependent, regardless of whether the colors are *in* gamut or *out* of gamut with respect to the very small bounded sRGB color gamut?

The exception to "all", of course, is when multiplying or dividing by black, gray, or white.

Yes I do understand that – The babl roadmap being incomplete/leaving room for interpretation is on purpose – what is stated there is the minimum roadmap bringing us towards a situation where such details makes sense to decide upon. Some operations we might change to not be chromaticity dependent in this way (for instance using CIE Lab or Lch) but for most of them the change will be using a babl-format specifiers like "target:RGBA" and "target:R'G'B'" instead of un-prefixed format specifiers like now, which in the future will be synonyms for "sRGB:RGBA" etc.

Somewhat switching gears, the revised babl roadmap (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says:

The plan in roadmap hasn't really changed since mid-april[1], revisions to the file has been integrating various bits lost in the mailinglist threads. The last revisions was to add what has been stated before in gimp-developer about single-precision floating point and accumulated rounding errors – since the issue was brought up here.

"Once a format has been resolved using babl_format(babl, "bar:RGBA float") the returned pointer would refer to the babl context that looked up "bar"'s definition of bar. This . . . allows rigging up a situation where the user has control over the RGB space used for chromaticity dependent operations."

In light of the revised roadmap and the above list of chromaticity dependent editing operations, I have two more questions. Again, I'm trying to establish common ground for communication, or at least clarify where we disagree.

1. Do you agree or disagree that for *all* chromaticity dependent editing operations, the *user* should be in control of which RGB chromaticities are used to perform the operation?

That is the point of adding more, and named, RGB families to babl.

Chromaticity dependent operations are the operations where we would use userRGB instead of bablRGB – effectively it being the way for the developer to say that for this operation the users chosen format should be used. using user:Y user:Y' user:R'G'B' and user:RGB would be different ways the op developer can request pixel formats based on this user choice; when the op developer knows it should (or should not) be linear of perceptual data. But also note that while in GIMPs use of babl/GEGL, there might only be one such user family of pixel formats controllable in one location of the UI, in the general flow based computing model of GEGL one might expect a single configured processing graph to have multiple userRGBs for photos coming from different sources.

2. Do you agree or disagree that for chromaticity *in*depedent editing operations (for example, and assuming linearized RGB: adding, scaling, gaussian blur, etc), the same results (same XYZ values) are obtained whether the operation is done in the user's chosen RGB working space or in unbounded sRGB?

I do; and if there wasn't any chromaticity dependent operations – a single "RGB family" like bablRGB would be sufficient – You convinced us to abandon that plan in april. If a GEGL graph contains multiple different userRGBs source buffers, chromaticity independent compositing operations compositing two buffers with different RGB chromaticities need to be converted to the same linear RGB. Initially this will be bablRGB; later – depending on profiling and time for doing it – we might end up making such compositing produce output in the same RGB family as the input buffer and convert the aux buffer to the same.

1: the only change in plans since then (and that changed occured before roadmap.txt was started), was abandoning the plan to do conversions between bablRGB and userRGBs in babl using LCMS2; and instead do those conversions directly ourselves in babl; a change without impact on how babl will be used by GEGL (and GIMP).

/pippin

Elle Stone
2014-11-17 14:43:21 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/16/2014 05:18 PM, Øyvind Kolås wrote:

On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone wrote:

Do you understand that when I say that Multiply is a chromaticity-dependent editing operation, I don't just mean the Multiply layer blend mode? that in fact *all* editing operations that use multiplication or division are chromaticity dependent, regardless of whether the colors are *in* gamut or *out* of gamut with respect to the very small bounded sRGB color gamut?

The exception to "all", of course, is when multiplying or dividing by black, gray, or white.

Yes I do understand that

OK, thanks! for confirming. I was afraid my phrasing might have obscured an important point.

1. Do you agree or disagree that for *all* chromaticity dependentediting operations, the *user* should be in control of which RGBchromaticities are used to perform the operation?

That is the point of adding more, and named, RGB families to babl.

2. Do you agree or disagree that for chromaticity *in*depedent editing operations (for example, and assuming linearized RGB: adding, scaling, gaussian blur, etc), the same results (same XYZ values) are obtained whether the operation is done in the user's chosen RGB working space or in unbounded sRGB?

I do;

So it appears that we agree on the following, yes?

1. The user's chosen RGB working space chromaticities should be used for performing all chromaticity dependent RGB editing operations.

2. For chromaticity independent RGB editing operations, the same XYZ values are obtained regardless of whether the operation is performed using the user's chosen RGB working space chromaticities or after converting the image to unbounded sRGB.

Somewhat switching gears, the revised babl roadmap (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says:

The plan in roadmap hasn't really changed since mid-april[1],

I agree with you that the plan you outlined in April is pretty much the same plan that I think you are outlining now. In April you did agree that some RGB editing operations don't work in unbounded sRGB. You said that using "targetRGB" (ie the user's chosen RGB working space, UserRGB, "bar"RGB, etc) would be one solution and that another solution would be converting to CIELAB to do the operation.

Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP:

1. Upon opening an image, the image will be converted to unbounded sRGB.

2. For all chromaticity dependent RGB editing operations: * Either the image will be re-encoded using the user's chosen RGB working space chromaticities, and then the operation will be performed. * Or else the image will be converted to CIELAB and then the operation will be performed.

3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing.

4. When converting to XYZ/CIELAB/etc, the image will first be converted to unbounded sRGB.

5. The GEGL developers will specify on an "operation by operation" basis whether the operation requires being encoded using UserRGB/Y/etc, or unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent RGB processing, or etc.

As an important note, depending on the last operation that was done, the image might already be encoded using the GEGL-operation-specified format, in which case a conversion to that format is not needed.

Are the above five points (and note) an accurate summary of your current plan for babl/GEGL/GIMP?

I have a couple of followup questions, but there's no point in asking them if I don't have a clear understanding of what your current plan really is. I think we've both been rightly accused of talking right past each other.

1: the only change in plans since then (and that changed occured before roadmap.txt was started), was abandoning the plan to do conversions between bablRGB and userRGBs in babl using LCMS2; and instead do those conversions directly ourselves in babl; a change without impact on how babl will be used by GEGL (and GIMP).

Using babl instead of LCMS2 to do ICC profile matrix conversions makes perfect sense, being faster and potentially a lot more accurate (https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00093.html).

/pippin

Elle

Simon Budig
2014-11-17 15:46:47 UTC (over 3 years ago)

Time to fork BABL and GEGL

Hi Elle.

The following is my understanding, when pippin answers his answers have more authority than mine.

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP:

A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data.

The important part is, that the data is available to the operations in the format they request upon request. If that is in memory already pre-converted or if that gets converted on the fly is an implementation detail.

1. Upon opening an image, the image will be converted to unbounded sRGB.

I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB. But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors.

2. For all chromaticity dependent RGB editing operations: * Either the image will be re-encoded using the user's chosen RGB working space chromaticities, and then the operation will be performed. * Or else the image will be converted to CIELAB and then the operation will be performed.

Conceptually the image won't be converted as a whole. A pixel-data-flow-graph will be set up that considers the region of interest.

For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format.

3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing.

For all chromaticity *in*dependent RGB editing operations the pixels will be converted to the format the operations requests. Which most likely will 0e sRGB or XYZ. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format.

(Sorry for repeating, but this is an important point: in a given image context "userRGB" really is not conceptually different from sRGB or XYZ, it gets slightly more complicated when two images with different user chromaticies are to be combined.)

4. When converting to XYZ/CIELAB/etc, the image will first be converted to unbounded sRGB.

Not necessarily. If specific userRGB to XYZ/whatever transforms are available to babl it will make use of them. This will likely be the case for e.g. AdobeRGB.

5. The GEGL developers will specify on an "operation by operation" basis whether the operation requires being encoded using UserRGB/Y/etc, or unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent RGB processing, or etc.

It probably will be specified within the implementation. I.e. there won't be a pre-existing separate document with a list for each individual operation.

However there might be such a document generated from the implementation.

As an important note, depending on the last operation that was done, the image might already be encoded using the GEGL-operation-specified format, in which case a conversion to that format is not needed.

Yes, but it is important to keep in mind that we don't sequentially apply one operation after each other, with image-in-memory-steps inbetween. We build a graph of connected operations, where the connections between the nodes will be negotiating the resp. pixel formats. *Then* the pixel data will be fed from the sources into the graph, flow through the graph, have the operations operate on them, potentially converting them to the negotiated pixel formats and finally get sunk into the output (e.g. the node painting into the image view).

Bye, Simon

simon@budig.de              http://simon.budig.de/
Elle Stone
2014-11-17 21:03:54 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/17/2014 10:46 AM, Simon Budig wrote:

Hi Elle.

The following is my understanding, when pippin answers his answers have more authority than mine.

Hi Simon,

I appreciate your answers, but the points you make aren't actually relevant to the questions that I wanted to ask Pippin. This is my fault. In an effort to clarify what I think he's saying, I seem to have just opened the door for more miscommunication.

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP:

A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data.

If you choose to *store* the user's RGB data using chromaticities not of user's choosing, that suggests that you also intend to *edit* the user's RGB data using chromaticities not of user's choosing

1. Upon opening an image, the image will be converted to unbounded sRGB.

I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors.

This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data.

2. For all chromaticity dependent RGB editing operations: * Either the image will be re-encoded using the user's chosen RGB working space chromaticities, and then the operation will be performed. * Or else the image will be converted to CIELAB and then the operation will be performed.

Conceptually the image won't be converted as a whole. A pixel-data-flow-graph will be set up that considers the region of interest.

This really is an implemetation detail.

For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB.

If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user really does expect that *all* RGB edits wil be done using the user's chosen RGB working space chromaticities.

3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing.

For all chromaticity *in*dependent RGB editing operations the pixels will be converted to the format the operations requests. Which most likely will 0e sRGB or XYZ.

This brings me to the question that I was planning on asking Pippin.

If Pippin *doesn't* intend to convert the image to unbounded sRGB before performing any RGB editing operations, then my question is irrelevant.

So the "pre question" is: Does Pippin intend that the image will be converted to unbounded sRGB before performing chromaticity *in*dependent RGB editing operations?

If Pippin's answer to the "pre question" is yes, here's the question I wanted to ask Pippin:

1. We've agree that many RGB editing operations really are chromaticity dependent and therefore should be done using the user's chosen RGB working space chromaticities.

2. We've agree that for chromaticity *in*dependent editing operations, the resulting colors as located in the XYZ reference color space are the same *regardless* of the chromaticities used to encode the RGB data before performing the operation.

Given the above two points of agreement, what is point of EVER converting the image to unbounded sRGB?

I can list a whole bunch of disadvantages. But I don't understand what the advantages are supposed to be.

I thought Jon Nordby had made it clear (more than once) that for all RGB editing operations, the user's chosen RGB working space's chromaticties would be used.

But it's hard to tell whether Pippin agrees with Jon Nordby.

So I'm asking Pippin as directly as possible whether he ever intends that RGB editing will be done using sRGB chromaticities instead of the user's chosen RGB working space's chromaticities.

If Pippin's answer is "yes", then the next question is "Why?".

(Sorry for repeating, but this is an important point: in a given image context "userRGB" really is not conceptually different from sRGB or XYZ,

My apologies, but this statement makes no sense unless you mean the trivially obvious point that RGB color data can be losslessly converted to various unbounded color spaces including the XYZ reference color space, of course putting aside floating point precision limitations and sundry other sources of computational loss of precision.

it gets slightly more complicated when two images with different user chromaticies are to be combined.)

Again, let the *user* decide what RGB working space to use for combining images. Except for the few compositing operations that are chromaticity independent, results will be different in different RGB working spaces.

4. When converting to XYZ/CIELAB/etc, the image will first be converted to unbounded sRGB.

Not necessarily.

Hmm, based on what Pippin has said previously, he wants to use linear gamma sRGB as a sort of pseudo-PCS
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00100.html). This seems to be for coding convenience, to take advantage of the current hard-coded babl conversion from sRGB to XYZ to LAB, and probably also from sRGB to Y.

So the "not necessarily" is a bit surprising.

And again, the babl hard-coded conversions that are specific to sRGB can be generalized to use the user's chosen RGB working space's Y and XYZ values, which automatically covers color-managed sRGB images.

If specific userRGB to XYZ/whatever transforms are available to babl it will make use of them. This will likely be the case for e.g. AdobeRGB.

OK, if I understand what you just said, this is getting silly.

I think you are indicating a willingness to write hard-coded AdobeRGB editing operations and put them right alongside the hard-coded sRGB editing operations.

And maybe you'd also add hard-coded ProPhotoRGB, hard-coded WideGamutRBB, hard-coded BetaRGB, and so forth.

And then you'd be faced with the problem that there are multiple variants of these profiles floating around open source image editing (http://ninedegreesbelow.com/photography/linux-icc-profiles.html).

Which would create the problem of deciding whether the user's chosen RGB working space was "close enough" to one of your hard-coded versions to warrant using the hard-coded paths.

And you'd still need generalized code for the RGB working spaces for which you haven't provided hard-coded paths.

You really do *not* want to walk down that particular coding path.

The only sensible thing to do is use LCMS to retrieve the user's chosen RGB working space's Y and XYZ values for the handful of editing operations that currently use hard-coded sRGB Y and XYZ values, and then generalize those operations, even for color-managed sRGB images.

I've already submitted the code to retrieve the user's RGB working space Y and XYZ values. I've already told you where in the code base all the hard-coded sRGB values that need to be generalized are located.

Sometimes I'm tempted to think that maybe the real problem is that the babl/GEGL/GIMP devs don't know how to code up generalized functions using Y and XYZ retrieved from the user's chosen RGB working space. But the devs are too smart, this can't possibly be the problem.

Bye,
Simon

Best regards,
Elle

Mikael Magnusson
2014-11-17 22:41:40 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone wrote:

On 11/17/2014 10:46 AM, Simon Budig wrote:

Hi Elle.

The following is my understanding, when pippin answers his answers have more authority than mine.

Hi Simon,

I appreciate your answers, but the points you make aren't actually relevant to the questions that I wanted to ask Pippin. This is my fault. In an effort to clarify what I think he's saying, I seem to have just opened the door for more miscommunication.

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP:

A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data.

If you choose to *store* the user's RGB data using chromaticities not of user's choosing, that suggests that you also intend to *edit* the user's RGB data using chromaticities not of user's choosing

1. Upon opening an image, the image will be converted to unbounded sRGB.

I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors.

This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data.

The above two things are implementation details as Simon said. If you don't understand this, then please don't write long articles full of misinformation that get widely quoted. Your answers suggest you didn't even understand what he said. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format.

Gegl stores pixels in memory in some format, it knows what format it used. Gimp can display/edit pixels in some color space (specified by the user). Gimp asks Gegl for pixels saying what colorspace it wants. Gegl presents the pixels to Gimp. All is well. It doesn't matter how the pixels are stored.

Mikael Magnusson
Elle Stone
2014-11-17 23:52:30 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/17/2014 05:41 PM, Mikael Magnusson wrote:

On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone wrote:

On 11/17/2014 10:46 AM, Simon Budig wrote:

I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors.

This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data.

The above two things are implementation details as Simon said.

There is no reason to *store* the image using the sRGB chromaticities unless you also intend to *edit* the image using the sRGB chromaticities, or else if you intend to convert the image to unbounded sRGB and then to Y or else to XYZ and then maybe to CIELAB.

So yes, the question of how you *store* the user's RGB data really does matter. It's not just an implementation detail.

Unless maybe you think it's reasonable to randomly re-encode the user's RGB data using the sRGB chromaticities "just because you can".

If you
don't understand this, then please don't write long articles full of misinformation that get widely quoted.Your answers suggest you didn't even understand what he said.

I do understand what Simon said. And I'm waiting for Pippin to clarify whether *Pippin* intends that images will be converted to unbounded sRGB before performing chromaticity independent RGB editing operations.

If Pippin's answer is "yes, the image will be converted to unbounded sRGB for chromaticity independent RGB editing operations", I want to ask him why. There are many bad consequences of doing this. So if Pippin's answer is "yes", there must be some advantages that I don't see.

Pippin and Jon Nordby seem to be saying different things. Three times Nordby has said that the image won't be converted to sRGB except for the handful of editing operations that really can't be generalized. (As an aside, in these cases, I hope a UI warning will be provided so the user knows what's going on and can exercise the right to not use the affected operation.)

And three times Pippin has made statements that seem to directly contradict Jon Nordby.

Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format.

Umm, could you untangle your analogy? Because all of sudden the integer encodings became undisplayable images.

I assure you that if you add integers encoded using binary, while thinking you are adding decimal numbers, you will almost certainly get results that diverge from what you expect, adding 0+1 being an obvious exception.

And if you composite colors thinking you are compositing in UserRGB, when really you are compositing in sRGB, likewise you are very likely to get results other than what you expected.

Gegl stores pixels in memory in some format, it knows what format it used.

babl and GEGL do communicate with each other as to what format the data is in and what format is needed next. Are you trying to say something else?

Gimp can display/edit pixels in some color space (specified by the user).

Well, this really is the question: according to Pippin, what color space chromaticities will be used for chromaticity independent RGB editing operations? UserRGB's or sRGB's?

Gimp asks Gegl for pixels saying what colorspace it wants.

Well, sometimes GIMP specifies the babl format and sometimes GEGL specifies the babl format. The question is whether for RGB editing operations the format so specified will ever be unbounded sRGB. Each time Nordby seems to say no, Pippin seems to say yes.

Gegl presents the pixels to Gimp.All is well. It doesn't matter how the pixels are stored.

Again, there is no reason to re-encode and *store* the pixels using the sRGB chromaticities *unless* there is an intention to *use* the re-encoded information for some purpose other than storing the pixels.

As GIMP is an image editor, presumably that purpose would be for *editing*, and the format the pixels are in for editing does matter a great deal.

Elle

Simon Budig
2014-11-17 23:56:48 UTC (over 3 years ago)

Time to fork BABL and GEGL

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data.

If you choose to *store* the user's RGB data using chromaticities not of user's choosing, that suggests that you also intend to *edit* the user's RGB data using chromaticities not of user's choosing

I think that this is the core of the misunderstanding here.

In Gegl the *storage* of pixel data in memory is totally and 100% independent from the colorspace used to *edit* the user's RGB data. You seem to think that the storage "suggests" an intent, but a lot of the communication from pippin, jonnor and me is about explaining that this is *not* the case.

Obviously it makes a lot of sense to bring storage and editing workspace in line to avoid computational bottlenecks. But this is just a performance optimization, i.e. implementation detail.

1. Upon opening an image, the image will be converted to unbounded sRGB.

I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors.

This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data.

We need to make sure two things:

a) upon import of an image the "userRGB"-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image.

b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the "userRGB" format from the images context.

Note that this is totally independent from the pixel *storage* in memory. This will work the same when the pixel *storage* is in userRGB, sRGB or XYZ.

For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB.

If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user really does expect that *all* RGB edits wil be done using the user's chosen RGB working space chromaticities.

We agree here. The *edits* for the chromaticity dependent operations need to be done in the chromaticies of the source image.

If specific userRGB to XYZ/whatever transforms are available to babl it will make use of them. This will likely be the case for e.g. AdobeRGB.

OK, if I understand what you just said, this is getting silly.

I think you are indicating a willingness to write hard-coded AdobeRGB editing operations and put them right alongside the hard-coded sRGB editing operations.

Oh, I was under the assumption that AdobeRGB had well defined chromaticies. If that is not the case then please consider my example moot. I am well aware that dealing with color profiles most definitely is not my area of expertise.

If there were chromaticies for a given "userRGB" which are widely used in a lot of real world applications, then it might make sense to support them in a similiar way like we currently do for the sRGB primaries.

If that is not the case then this indeed would be silly.

Bye, Simon

simon@budig.de              http://simon.budig.de/
Øyvind Kolås
2014-11-18 00:08:10 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Mon, Nov 17, 2014 at 11:56 PM, Simon Budig wrote:

If there were chromaticies for a given "userRGB" which are widely used in a lot of real world applications, then it might make sense to support them in a similiar way like we currently do for the sRGB primaries.

Nah, we only need one unbounded PCS ;) – other linear RGB spaces, like linear adobeRGB, are a matrix transform away from linear bablRGB. There might however be some non-similar ways to optimize things, however many of those likely add decision overhead in scenarios like per scanline calls for partial tile conversions that cancel out the benefit over just doing a straight matrix transform.

/pippin

Ed .
2014-11-18 00:32:30 UTC (over 3 years ago)

Time to fork BABL and GEGL

Elle,

If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose.

Ed

-----Original Message----- From: Elle Stone
Sent: Monday, November 17, 2014 11:52 PM To: Mikael Magnusson
Cc: gimp-user-list@gnome.org ; gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/17/2014 05:41 PM, Mikael Magnusson wrote:

On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone wrote:

On 11/17/2014 10:46 AM, Simon Budig wrote:

I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors.

This is not just an implementation detail. The user has the right to control
what RGB working space is used when performing RGB edits on the user's own
RGB data.

The above two things are implementation details as Simon said.

There is no reason to *store* the image using the sRGB chromaticities unless you also intend to *edit* the image using the sRGB chromaticities, or else if you intend to convert the image to unbounded sRGB and then to Y or else to XYZ and then maybe to CIELAB.

So yes, the question of how you *store* the user's RGB data really does matter. It's not just an implementation detail.

Unless maybe you think it's reasonable to randomly re-encode the user's RGB data using the sRGB chromaticities "just because you can".

If you
don't understand this, then please don't write long articles full of misinformation that get widely quoted.Your answers suggest you didn't even understand what he said.

I do understand what Simon said. And I'm waiting for Pippin to clarify whether *Pippin* intends that images will be converted to unbounded sRGB before performing chromaticity independent RGB editing operations.

If Pippin's answer is "yes, the image will be converted to unbounded sRGB for chromaticity independent RGB editing operations", I want to ask him why. There are many bad consequences of doing this. So if Pippin's answer is "yes", there must be some advantages that I don't see.

Pippin and Jon Nordby seem to be saying different things. Three times Nordby has said that the image won't be converted to sRGB except for the handful of editing operations that really can't be generalized. (As an aside, in these cases, I hope a UI warning will be provided so the user knows what's going on and can exercise the right to not use the affected operation.)

And three times Pippin has made statements that seem to directly contradict Jon Nordby.

Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format.

Umm, could you untangle your analogy? Because all of sudden the integer encodings became undisplayable images.

I assure you that if you add integers encoded using binary, while thinking you are adding decimal numbers, you will almost certainly get results that diverge from what you expect, adding 0+1 being an obvious exception.

And if you composite colors thinking you are compositing in UserRGB, when really you are compositing in sRGB, likewise you are very likely to get results other than what you expected.

Gegl stores pixels in memory in some format, it knows what format it used.

babl and GEGL do communicate with each other as to what format the data is in and what format is needed next. Are you trying to say something else?

Gimp can display/edit pixels in some color space (specified by the user).

Well, this really is the question: according to Pippin, what color space chromaticities will be used for chromaticity independent RGB editing operations? UserRGB's or sRGB's?

Gimp asks Gegl for pixels saying what colorspace it wants.

Well, sometimes GIMP specifies the babl format and sometimes GEGL specifies the babl format. The question is whether for RGB editing operations the format so specified will ever be unbounded sRGB. Each time Nordby seems to say no, Pippin seems to say yes.

Gegl presents the pixels to Gimp.All is well. It doesn't matter how the pixels are stored.

Again, there is no reason to re-encode and *store* the pixels using the sRGB chromaticities *unless* there is an intention to *use* the re-encoded information for some purpose other than storing the pixels.

As GIMP is an image editor, presumably that purpose would be for *editing*, and the format the pixels are in for editing does matter a great deal.

Elle

Gez
2014-11-18 01:20:09 UTC (over 3 years ago)

Time to fork BABL and GEGL

El mar, 18-11-2014 a las 00:32 +0000, Ed . escribió:

Elle,

If you don't understand the difference between a design detail, and an
implementation detail, you need to either a) go away and get to understand
that difference; or b) stop commenting. I am neutral as to which you choose.

Ed

Are you the same Ed. who wanted to "ease communication" between Elle and pippin? If not, plase give us back the old Ed. we liked him better.

You seem a tad biased for someone who admittedly doesn't understand the issue being discussed.

Do you really think that asking someone to STFU helps here?

Gez.

Gez
2014-11-18 01:48:12 UTC (over 3 years ago)

Time to fork BABL and GEGL

El lun, 17-11-2014 a las 23:41 +0100, Mikael Magnusson escribió:

The above two things are implementation details as Simon said. If you don't understand this, then please don't write long articles full of misinformation that get widely quoted. Your answers suggest you didn't even understand what he said. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format.

Gegl stores pixels in memory in some format, it knows what format it used. Gimp can display/edit pixels in some color space (specified by the user). Gimp asks Gegl for pixels saying what colorspace it wants. Gegl presents the pixels to Gimp. All is well. It doesn't matter how the pixels are stored.

I think I have at this point a reasonable grasp of what's the plan here and that unbounded sRGB is intended a just one representation of the many possible with babl (and that its primary function is to be used as a PCS)-

I also understand that chromaticity dependent operations will use userRGB.

However, and this is what Elle is asking and nobody seems to understand, the question is if bablRGB is still going to be used as the RGB space for all the chromaticity independent operations and if that's a yes, then WHY.
Is it just to spare one single matrix transform in case the buffer is not available in userRGB?

And yes, jonnor said something that seems to contradict pippin if that's the case: in the future RGB operations that now ask for bablRGB should ask for userRGB instead.

That of course doesn't take bablRGB out of the picture (it would still would be used as PCS), but means specifically that operations won't be fed anymore with unbounded sRGB but user defined RGB.

When Elle says "converting to unbounded sRGB", she's referring to what babl will do when an operation requests for bablRGB. (We know it's not a forced conversion at the beginning of the pipe, and the GEGL tree can keep different representations for the buffer).

If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available.

Could you please address that question with a straight answer?

Gez.

Michael Henning
2014-11-18 02:19:35 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Mon, Nov 17, 2014 at 8:48 PM, Gez wrote:

If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available.

Could you please address that question with a straight answer?

It's very likely that the processing will happen in userRGB for performance reasons.

Nobody wants to give you a straight answer because to be honest, we don't know for sure. We could change our mind at any point in the future, and you wouldn't know without reading the code. It doesn't matter what space they happen in because chromaticity independent operations, by definition, do not care which of the spaces we pass them. If we do find a compelling reason to have those operations happen in bablRGB (performance or numerical stability, for example), then we reserve the right to do those operations in bablRGB. And if we do, then nobody will ever know the difference, other than the whopping three people that will ever read that section of the gegl code.

Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it *by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it?

-- drawoc

Gez
2014-11-18 04:39:43 UTC (over 3 years ago)

Time to fork BABL and GEGL

El lun, 17-11-2014 a las 21:19 -0500, Michael Henning escribió:

On Mon, Nov 17, 2014 at 8:48 PM, Gez wrote:

If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available.

Could you please address that question with a straight answer?

It's very likely that the processing will happen in userRGB for performance reasons.

Nobody wants to give you a straight answer because to be honest, we don't know for sure. We could change our mind at any point in the future, and you wouldn't know without reading the code. It doesn't matter what space they happen in because chromaticity independent operations, by definition, do not care which of the spaces we pass them. If we do find a compelling reason to have those operations happen in bablRGB (performance or numerical stability, for example), then we reserve the right to do those operations in bablRGB. And if we do, then nobody will ever know the difference, other than the whopping three people that will ever read that section of the gegl code.

Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it *by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it?

Sure.
My main concern is performance. It doesn't seem likely that flip-flopping between pixel formats can be more performant than just tossing the user RGB to operations.
It's already necessary for chromaticity dependent operations, so why not just using it for EVERY RGB operation? There are benefits: The channel data is always in the range the users expects, color pickers pick the data the user expects, and that requires exactly zero conversions.

Please note that my question was related ONLY to what RGB operations take and give. If you have a compelling reason to keep an extra representation (bablRGB) as PCS for converting to other color models and give me channels for my processing needs, great. But is there a compelling reason to change RGB from the RGB users choose to something else?

Gez.

P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive?

Michael Henning
2014-11-18 08:05:27 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Mon, Nov 17, 2014 at 11:39 PM, Gez wrote:

P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive?

Yes, I think that discussing this is counterproductive because it is premature. If I had spent the time I spent responding to color-related emails on coding this system instead, it would easily be working right now. Then, we could be discussing the details of a system that actually existed, instead of the details of a system that does not exist, and if current rates of coding continue, will never exist.

You say I should stop responding, but it's hard to stop responding when novels are being written about how wrong you are, but you believe you are right. It's hard to stop responding when an article portraying you as incompetent appears on hacker news. It's hard to stop responding when you genuinely want people to understand.

-- drawoc

Elle Stone
2014-11-18 10:16:22 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/17/2014 06:56 PM, Simon Budig wrote:

Oh, I was under the assumption that AdobeRGB had well defined chromaticies. If that is not the case then please consider my example moot. I am well aware that dealing with color profiles most definitely is not my area of expertise.

It absolutely does have well-defined chromaticities.

LCMS specifies an odd value for D65 and doesn't compensate for hexadecimal rounding. And so almost everyone who distributes ICC profiles made with LCMS makes AdobeRGB1998-compatible profiles that don't exactly match the Adobe specifications.

Graham Gill distributes ClayRGB1998.icm that exactly matches the Adobe specs. I've submitted code to GIMP to make a proper AdobeRGB1998-compatible profile.

Other free/libre profile makers really aren't distributing an exact match to the Adobe specs. I've already reported this on the LCMS mailing list.

Similar problems obtain with a lot of other free/libre ICC profiles.

Elle

Elle Stone
2014-11-18 10:17:48 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/17/2014 07:32 PM, Ed . wrote:

Elle,

If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose.

Ed

Again, Ed, in this discussion you don't have a leg to stand on.

Ed .
2014-11-18 15:27:15 UTC (over 3 years ago)

Time to fork BABL and GEGL

Great! Glad to hear it!

Please prove to us your understanding by expressing, in your own words, the difference between a design detail and an implementation detail.

Ciao, Ed

-----Original Message----- From: Elle Stone
Sent: Tuesday, November 18, 2014 10:17 AM To: Ed . ; Mikael Magnusson
Cc: gimp-user-list@gnome.org ; gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/17/2014 07:32 PM, Ed . wrote:

Elle,

If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose.

Ed

Again, Ed, in this discussion you don't have a leg to stand on.

Simos Xenitellis
2014-11-18 15:50:36 UTC (over 3 years ago)

Time to fork BABL and GEGL

These are the type of emails that are not helpful. It is not helpful also because it's a rephrased email that was sent 15 hours ago.

Simos

On Tue, Nov 18, 2014 at 5:27 PM, Ed . wrote:

Great! Glad to hear it!

Please prove to us your understanding by expressing, in your own words, the difference between a design detail and an implementation detail.

Ciao, Ed

-----Original Message----- From: Elle Stone Sent: Tuesday, November 18, 2014 10:17 AM To: Ed . ; Mikael Magnusson
Cc: gimp-user-list@gnome.org ; gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/17/2014 07:32 PM, Ed . wrote:

Elle,

If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose.

Ed

Again, Ed, in this discussion you don't have a leg to stand on.

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

Alexandre Prokoudine
2014-11-18 15:55:50 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Tue, Nov 18, 2014 at 6:27 PM, Ed . wrote:

Great! Glad to hear it!

Please prove to us

If you have personal issues with any of the list members, I strongly advice taking it off-list.

We'd like to keep the interaction professional, thank you.

Alex

Elle Stone
2014-11-18 16:00:23 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/18/2014 03:05 AM, Michael Henning wrote:

On Mon, Nov 17, 2014 at 11:39 PM, Gez wrote:

P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive?

Yes, I think that discussing this is counterproductive because it is premature. If I had spent the time I spent responding to color-related emails on coding this system instead, it would easily be working right now.

If I had not spent time and effort explaining the problems *before* you got around to implementing unbounded sRGB image editing, you would have coded up a "working" high bit depth GIMP that was steadily churning out wrong results. And I'd be filing a whole lot of bug reports.

Then, we could be discussing the details of a system that actually existed, instead of the details of a system that does not exist, and if current rates of coding continue, will never exist.

And the discussion would be exactly the same. You would still need to use UserRGB chromaticities instead of sRGB chromaticities. But you'd have to undo a lot of new code to get there.

Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y:

* https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages
* http://ninedegreesbelow.com/photography/srgb-luminance.html.

Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See:

GIMP really does need someone on the team who understands ICC profile color management. But it doesn't do any good to have such a person around unless you actually listen.

To listen *intelligently* so you can ask the right questions when your color management person seems to be giving wrong advice (I'm just as capable as the next person when it comes to giving wrong advice), you need to understand a little bit about ICC profile color management. I've done my best to make this task easier:

Completely Painless Programmer's Guide to XYZ, RGB, ICC, xyY, and TRCs http://ninedegreesbelow.com/photography/xyz-rgb.html

I've learned a lot while trying to explain where babl/GEGL/GIMP has gone off track regarding one or another color management issue. Hopefully the exchange of knowledge has been a two-way street.

You say I should stop responding, but it's hard to stop responding when novels are being written about how wrong you are, but you believe you are right. It's hard to stop responding when an article portraying you as incompetent appears on hacker news. It's hard to stop responding when you genuinely want people to understand.

-- drawoc

I agree with you that it's hard to stop responding when you want people to understand something that you care about. I doubt whether any of you have a clue just how much I value GIMP as an RGB image editor. But GIMP is critically important to free/libre artists and therefore GIMP color management needs to be right.

Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it*by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it?

This is exactly the right question. It will me take a bit of time to put together a straight answer that is also not one of my "walls of words". I'll try to post the answer today or at least by tomorrow morning.

Elle

Elle Stone
2014-11-18 16:05:11 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/18/2014 11:00 AM, Elle Stone wrote:

Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y:

* https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages
* http://ninedegreesbelow.com/photography/srgb-luminance.html.

Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See:

Sorry, typo, the "See:" is misplaced. It should read:

Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y See:

* https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages
* http://ninedegreesbelow.com/photography/srgb-luminance.html.

Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values.

Elle

Simon Budig
2014-11-18 16:15:02 UTC (over 3 years ago)

Time to fork BABL and GEGL

As a small aside...

Alexandre Prokoudine (alexandre.prokoudine@gmail.com) wrote:

We'd like to keep the interaction professional, thank you.

I'd like to ask everyone involved in this discussion to remove the gimp-user mailinglist from the CC-list. The level of this discussion really is hardcore gimp-devel stuff and there is no need to duplicate it on gimp-user.

People on gimp-user who are interested in this discussion are welcome to join gimp-devel.

Let this be the last mail in this thread duplicated to both of the lists :)

Thanks, Simon

simon@budig.de              http://simon.budig.de/
Alexandre Prokoudine
2014-11-18 16:16:15 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Tue, Nov 18, 2014 at 7:00 PM, Elle Stone wrote:

Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See:

Elle, assuming that things are not done/fixed, because we don't understand them or don't care about them, is simply incorrect. We have a roadmapful of things we care about which still need someone to work on. It really is that easy.

By now, it's been repeated about a dozen of times that we had adjusted our plans in the past to honor your useful input, and we are going to do so in the future __time permitting__. Is there a good reason why there should be another dozen of times for this to be said in the public?

As Michael already stated, there are things we simply don't know yet, because they are implementation details. hence we don't have all the answers for you. Please show us some patience.

Alex

Elle Stone
2014-11-18 17:39:06 UTC (over 3 years ago)

Time to fork BABL and GEGL

In keeping with Simon's request, I'm not copying the user list.

On 11/18/2014 11:16 AM, Alexandre Prokoudine wrote:

On Tue, Nov 18, 2014 at 7:00 PM, Elle Stone wrote:

Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See:

Elle, assuming that things are not done/fixed, because we don't understand them or don't care about them, is simply incorrect. We have a roadmapful of things we care about which still need someone to work on. It really is that easy.

I didn't mean to offend anyone and my apologies if I did.

Not too long ago I wanted to submit a patch for the GIMP sRGB Y values. I was told by one of the developers that it was still undecided as to whether D65 or D50-adapted Y values were appropriate. This would have been a small code change to make. I would have done the required coding, so it would have required no developer time except the time to make the commit. It would have brought GIMP Y into line with babl Y.

There was no reason to not accept the change other than a failure to understand that in an ICC profile color-managed application where the profile illuminant is D50, using D65 unadapted Y values is incorrect. This is not casting blame. This is describing a situation where the required knowledge for making a decision simply wasn't there.

I used to tutor math students and learned very quickly that the only way to get information from teacher to student is to enable the student to ask the right questions, which means trying to see things from the student's perspective.

Before I suggest anything related to color management to the GIMP devs, I've already tested it sixteen ways from Sunday. In the cases of "which Y" and the inadvisability of using sRGB chromaticities for editing images that the user intends to be in some other RGB working space, my advice is correct.

But explaining why really is taking a long time and also is trying everyone's patience, including mine. I think part of the problem is people (no doubt including me) aren't asking the right questions.

I've been trying to understand the babl/GEGL/GIMP perspective on color management. I've also been trying to impart enough information to enable the devs to ask me the right questions, but I don't seem to be doing a very good job.

By now, it's been repeated about a dozen of times that we had adjusted our plans in the past to honor your useful input, and we are going to do so in the future __time permitting__. Is there a good reason why there should be another dozen of times for this to be said in the public?

Actually I feel very honored that you all trust my input enough to make changes. And I do realize that tasks need to be prioritized. For instance, I expect you probably will release 2.10 before fixing the hard-coded sRGB parameters. Rome wasn't built in a day and even I will agree that getting GIMP geglified and removing more of the deprecated functions is a higher priority task than fixing GIMP color management.

As Michael already stated, there are things we simply don't know yet, because they are implementation details. hence we don't have all the answers for you. Please show us some patience.

Well, I've been patiently explaining why some of those "implementation details" really belong over in the "overall plan" category. And you all have been extraordinarily patient with my efforts to communicate.

Elle

Saul Goode
2014-11-19 10:49:32 UTC (over 3 years ago)

Time to fork BABL and GEGL

Simon Budig wrote:

We need to make sure two things:> a) upon import of an image the "userRGB"-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image.

b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the "userRGB" format from the images context.

With regard to "b)", it is conceivable that the chromaticity dependent operation itself could be transformed to take into account the userRGB format description, such that the resulting transformed operation could be applied directly to the unbounded RGB data. In cases where doing so is advantageous, the implementer should have that option. The requirement should only be thatthe infrastructure produce the same result as if the operation were working in the userRGB colorspace.

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


 
 > 
> a) upon import of an image the "userRGB"-format-descriptor within the
images context needs to be set up to refer to the chromaticies of the
source image.

b) whenever a chromaticity dependent operation works on the images data
the infrastructure needs to make sure that the pixel data gets fed into
the operation using the chromaticies of the source image. We'll do this
by having the operation request the image data in the "userRGB" format
from the images context.
Elle Stone
2014-11-19 19:31:28 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/18/2014 03:05 AM, Michael Henning wrote

Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it*by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it?

As usual I've written too many words and yes I've covered some of the points before. But this time there's an outline and an organized presentation.

We've agreed that for chromaticity dependent RGB editing operations ("CD ops", for short), editing in UserRGB versus unbounded sRGB will produce different results (except in the limiting case where UserRGB is sRGB), and so the correct thing to do is perform the edits using UserRGB chromaticities.

We've also agreed that for chromaticity independent RGB editing operations ("CI ops", for short), by definition the same colors (as located in the XYZ reference color space) are obtained regardless of the chromaticities that are used to encode the data.

Nonetheless CI ops should be done using UserRGB chromaticities.

Summary: Performing CI ops using sRGB chromaticities requires a whole lot of otherwise unnecessary implementation details and also requires identifying which operations really are CI. Proposed CIELAB workarounds won't work.

Outline:

1. Editing in alternate versions of GIMP that do and don't convert to unbounded sRGB for CI ops

2. Precision and CPU considerations

3. The onerous task of deciding which ops are CI ops

4. Dealing with Histograms, FG/BG Colors, Color Picker, and Gradients

5. CIELAB as a replacement for displaying and picking RGB colors: not a good idea

6. Replacing chromaticity dependent RGB ops with CIELAB ops: not a good idea

7. Moving past unbounded sRGB to HDR scene-referred editing

1. Editing in alternate versions of GIMP that do and don't convert to unbounded sRGB for CI ops:

Assume Person A is using a version of GIMP that uses UserRGB for all ops. Person A performs a CI op involving one or more image layers, followed by a CD op.

Assume Person B is using a version of GIMP that converts the image layer(s) to unbounded sRGB for all CI ops. Person B performs the same CI op as Person A, and then the image layer(s) are converted back to UserRGB for the CD op.

GIMP is a display-referred image editor and so all editing operations are presumed to be working on RGB channel values that are clipped to fit within the UserRGB channel data range 0.0 to 1.0.

When shooting raw, it's incredibly easy to record colors that exceed the very small bounded sRGB color gamut. Accordingly, converting the image from UserRGB to unbounded sRGB for CI ops will require unclipping all the CI ops. And upon conversion back to UserRGB, the unbounded sRGB colors will need to be clipped to the UserRGB color gamut.

If the CI op in question is a layer blend mode, then in reality to get the same UserRGB channel values as Person A, Person B will need to make a "New from Visible" layer from the blended layers, and then convert back to UserRGB.

Of course babl/GEGL/GIMP code can be added that makes this "New from Visible" layer be created automatically. And so you can consider this new code to be an implementation detail.

But now Person B is forced to deal with an additional layer in the stack that Person A doesn't have to deal with. But presumably a way can be coded up to make this "New from Visible" layer invisible to the user.

Throw a mask on the top blended layer. Now every time Person B modifies the mask, a new conversion to unbounded sRGB and a new "New from Visible" layer will need to be made before the layers are converted back to UserRGB.

Person A, of course, doesn't need a "New from Visible" layer.

If UserRGB is used for both CD and CI ops, there is no need to worry dealing with CI layer blend modes or unclipping CI ops and then clipping the unbounded results to fit within the UserRGB color gamut.

2. Precision and CPU considerations:

If CI ops are performed using sRGB chromaticities and CD ops are performed using UserRGB chromaticities, then every time a CI op is followed by a CD op, or vice versa, a conversion between UserRGB and sRGB will be required.

Let's make the assumption that babl/GEGL/GIMP throughput precision is equal to theoretical floating point precision (does anyone really think this is the case?). Even so, CPU time is required to perform conversions between UserRGB and unbounded sRGB.

Pippin has been working very hard to shave seconds off of various editing operations. It seems at best questionable to code up CPU-consuming conversions between UserRGB and unbounded sRGB only to get the same colors that UserRGB would have produced. So it's better to use UserRGB for both CD and CI ops.

3. The onerous task of deciding which ops are CI ops:

When performed on linearized RGB data, the list of chromaticity dependent editing operations is long, comprising over half of the roughly 80 GIMP UI operations that I checked.

When performed on perceptually uniform RGB data, the list of CD ops is much, much longer.

If the decision is made to perform CI editing operations in the unbounded sRGB color space, then the developers have to take on the responsibility of making sure that they don't make mistakes about which ops are CI and which are CD. Even if no official list is made, in effect the devs will be tasked with "making a list and checking it twice", which is fine if you are Santa Claus and have a lot of elvish help.

Performing all CI ops using the UserRGB chromaticities already produces correct results. Using UserRGB for CI ops never runs the risk of producing incorrect results because a developer didn't realize that "operation X" really was a CD op rather than a CI op.

So it seems to me that developer time is better spent on priorities other than figuring out which ops are CI and which are CD. If you always use UserRGB, the question never arises as to whether an editing op is CI or CD.

4. Dealing with Histograms, FG/BG Colors, Color Picker, and Gradients:

Let's assume the design decision is made to convert the image from UserRGB to unbounded sRGB for all CI ops.

Either the developers will need to code up histograms (Levels and Curves histograms as well as Info/Histogram) that show the out of gamut unbounded sRGB channel values (currently everything is clipped to the 0.0 to 1.0 range).

Or else the histogram displays will need to be shown using UserRGB channel values, even when the image layer is encoded using the sRGB chromaticities.

Similar considerations apply for selecting FG/BG Colors.

As the user really cannot be expected to understand the editing implications of those out of gamut sRGB-encoded channel values, the better course is to always display UserRGB-encoded channel values even when the image layer has been re-encoded using sRGB chromaticities.

The same is true for colors displayed by the Color Picker. To show why, consider the following:

On the one hand, everyone knows that in the ProPhotoRGB color space, ProPhotoRGB's reddest red is (1.0000, 0.0000, 0.0000).

On the other hand, GIMP users really cannot be expected to know that when encoded using linear gamma sRGB, (2.0344, -0.2288, -0.0085) is the same as ProPhotoRGB's reddest red.

Nor should users be expected to know that when encoded using perceptually uniform sRGB, (1.3633, 2.9569, -0.1104) is the same as ProPhotoRGB's reddest red. When a user color picks an RGB color, the user expects that color to be expressed as a *User*RGB color, not an unbounded sRGB color.

5. CIELAB as a replacement for displaying and picking RGB colors: not a good idea

A proposed alternative for picking and displaying unbounded sRGB-encoded colors is displaying colors in the CIELAB reference color space. In practice, LAB colors would be an invaluable *addition* to Color Picker and FB/BG Colors, especially if the boundary between real and imaginary colors could also be displayed.

But displaying CIELAB channel values is completely inadequate as a *replacement* for displaying UserRGB channel values because users sometimes really do need to know the actual UserRGB channel values.

For example, CIELAB colors are not going to help if UserRGB is AdobeRGB and the user wants to draw a linear gamma gradient from AdobeRGB reddest red to AdobeRGB greenest green.

For another example, if the user needs to know whether the Blue channel value is less than the Green channel value, then again the equivalent CIELAB values are useless.

Dismissing these cases as "corner cases" just won't fly. These "CIELAB won't work" examples represent critically important use cases for RGB image editing (at least for anyone who has moved past the "push the slider and see what happens" approach to image editing).

6. Replacing chromaticity dependent RGB ops with CIELAB ops: not a good idea

CIELAB is a wonderful *adjunct* to RGB image editing. But there is no case where a CD op OR a CI op should be *replaced* by a CIELAB op. The data coming off the camera sensor really is RGB data, not CIELAB data.

Operating on linearized RGB data allows photometrically ("radiometrically") correct editing. BY DESIGN, CIELAB is not a photometrically correct color space:

* Color correction in CIELAB is useful, but it can't substitute for RGB color correction.

* Gradients drawn in CIELAB are necessarily *not* photometrically correct gradients.

* Multiplying colors in CIELAB can't be used to transform the colors "as if" a physical color filter had been applied to the scene light source when the image was photographed.

* CIELAB channel data is radically different from UserRGB channel data. Converting from one RGB color space to the next rearranges channel data, "only" introducing crosstalk. Converting from RGB data to CIELAB goes way beyond introducing crosstalk and instead re-encodes the data in a completely different color space model that intentionally separates "opponent colors" from lightness.

* Many useful things that can be done using LAB Levels and Curves adjustments. None of them are substitutes for linear gamma RGB Levels and Curves adjustments.

7. Moving past unbounded sRGB to HDR scene-referred editing

Currently GIMP is a display-referred image editor. The point of display-referred image editing is to be able to "display" an image's entire dynamic range on a "device".

During display-referred image editing the "display device" is the user's monitor screen. When editing is finished, the "display device" might be a paper print, LCD or other display screen, or etc.

When editing an image in a display-referred image editor, the RGB working space device "white" (R=G=G=1.0) is mapped to "device white". Likewise RGB black (R=G=B=0) is mapped to "device black".

This means the display-referred dynamic range is limited to roughly 9 stops, depending on where you draw the cut-off between "just noticeably dark gray" and "visually the same as black". See "Models for image editing: Display-referred and scene-referred" (http://ninedegreesbelow.com/photography/display-referred-scene-referred.html).

Real world scenes can have dynamic ranges that exceed 20 stops. In an HDR scene-referred image editor, R=G=B=1.0 is just another point on a grayscale that runs from 0 (no light) to some very high value that is mostly determined by considerations of precision.

If I understand Pippin correctly, he has anticipated the ICC's move to eventually accomodate HDR scene-referred image editing and I'm pretty sure he's been laying the groundwork for transforming GIMP into an HDR "scene referred" image editor.

For GIMP to be an HDR scene-referred image editor, clipping code really must be removed and ALL editing must be done using UserRGB channel values. Otherwise the user's task of interpreting the resulting RGB channel values becomes impossible because the user won't have any way of knowing whether RGB channel values are in or out of gamut with respect to the UserRGB xy chromaticities.

For GIMP to be an HDR scene-referred image editor and *also* a display-referred image editor, of course the user must be able to flip between a mode where all UserRGB channel values are clipped to the range 0.0 to 1.0, and a mode where the channel values are unclipped to acccomodate HDR channel values.

Anyway, if I'm correct, and HDR scene-referred image editing really is what Pippin has in mind for GIMP, it would be nice to move past discussing unbounded *s*RGB (it really is not a good idea) and move on to discussing the options that unbounded *User*RGB image editing can open up.

In unbounded *User*RGB, a color's RGB channel values and hence Luminance (Y value) can be as high as required to capture the scene dynamic range. But RGB channel values will never be negative except if the *user* makes an editing move that deliberately produces such values for whatever purpose the user has in mind.

I've already been making use of some of what high bit depth GIMP would be able to do in this respect (for example using the unbounded *User*RGB Levels upper sliders), and it opens up some pretty cool editing options even for what would otherwise be normal display-referred image editing.

Elle

Øyvind Kolås
2014-11-19 20:27:27 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone wrote a lot of text that has been
trimmed away...

I am only going to reply to the issues you seem to have with color image processing algorithms operating in CIE Lab. My general stance is that if at all possible, algorithms should operate on linear RGB data. Some algorithms do however not work well on linear data and expect more of a perceptually uniform color space to give satisfying results. Many of the ops fitting this categorization - both in GIMP and GEGL have been using sRGB; even if academic papers introducing/describing the algorithms specifies that processing is to be done in CIE Lab. Such operations might be using division, multiplication, power functions and other chromaticity dependent arithmetic building blocks. It is for these type of operations using CIE Lab should be evaluated rather than UserRGB – just like CIE Lab can be considered for new color image processing ops that rely on more perceptual uniformity than linear RGBs provide.

/pippin

Elle Stone
2014-11-19 21:28:26 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/19/2014 03:27 PM, Øyvind Kolås wrote:

On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone wrote a lot of text that has been
trimmed away...

Hmm.

I worked hard to explain why even for chomaticitiy independent editing operations the RGB data shouldn't be converted to unbounded sRGB.

You dismissed my efforts with "Elle Stone wrote a lot of text that has been trimmed away..."

Elle

Øyvind Kolås
2014-11-19 21:47:53 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Wed, Nov 19, 2014 at 9:28 PM, Elle Stone wrote:

On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone wrote a lot of text that has been
trimmed away...

Hmm.

I worked hard to explain why even for chomaticitiy independent editing operations the RGB data shouldn't be converted to unbounded sRGB.

You dismissed my efforts with "Elle Stone wrote a lot of text that has been trimmed away..."

I think it is too early to productively discuss implementation details in GEGL, and therefore choose to focus on things that are *not* implementation details.

Thankfully you no longer seem to disagree with the general direction of the babl roadmap as can be seen in your reference to how the architecture of babl/GEGL goes beyond traditional ICC RGB editing, encompasses HDR.

There is much work to be done in babl – by someone; not neccesarily me – before it is possible to experiment with different approaches. When we can profile running code, see what the CPU is busy doing most of the time and then spend time refactoring unneccesary conversions away. I have even speculated and pointed out likely complications for some of the chromaticity independent operations when *different* user:RGBs are to be composited. To repeat an earlier remark on one of the other points, there is no lists to maintain of which operations operate with what representation – this is local to the ops. Each individual operation within its own code specifies the data representation of input and output data in its own implementation.

/pippin

Elle Stone
2014-11-19 22:57:04 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/19/2014 04:47 PM, Øyvind Kolås wrote:

On Wed, Nov 19, 2014 at 9:28 PM, Elle Stone wrote:

On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone wrote a lot of text that has been
trimmed away...

Hmm.

I worked hard to explain why even for chomaticitiy independent editing operations the RGB data shouldn't be converted to unbounded sRGB.

You dismissed my efforts with "Elle Stone wrote a lot of text that has been trimmed away..."

I think it is too early to productively discuss implementation details in GEGL, and therefore choose to focus on things that are *not* implementation details.

Whether to *ever* use unbounded sRGB chromaticities to perform edits on UserRGB data is NOT AN IMPLEMENTATION DETAIL.

Unbounded sRGB is a mistake, pure and simple, *unless* the data is intended by the USER to be HDR sRGB data.

In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results.

Converting a display-referred wider gamut image to unbounded sRGB doesn't magically produce HDR data. It just creates a mess that will require a bunch of onerous implementation details to straighten out.

There is *no* point in *ever* editing UserRGB data using sRGB chromaticities. You can call all the shenanigans that would be required to straighten out the resulting mess "implementation details" if you want. But it's still a mistake to edit UserRGB data using ANY chromaticities not of the user's choosing.

Thankfully you no longer seem to disagree with the general direction of the babl roadmap as can be seen in your reference to how the architecture of babl/GEGL goes beyond traditional ICC RGB editing, encompasses HDR.

The ONLY part of the babl/GEGL architecture I've ever disagreed with is your desire to force UserRGB to be re-encoded using sRGB chromaticities.

Other than unbounded sRGB, what you've been trying to do is *brilliant*.

Even brilliant people sometimes have ideas that turn out to be not so great.

There is much work to be done in babl – by someone; not neccesarily me – before it is possible to experiment with different approaches.

You don't need to experiment with vs not converting UserRGB to unbounded sRGB.

Converting UserRGB to chromaticities not of the user's choosing is a mistake. All it does is create unnecessary complications.

You shouldn't be trying to control what RGB working space the user is allowed to use to edit the user's own RGB data.

When
we can profile running code, see what the CPU is busy doing most of the time and then spend time refactoring unneccesary conversions away. I have even speculated and pointed out likely complications for some of the chromaticity independent operations when *different* user:RGBs are to be composited.

When the user wants to composite images together, the only thing you can *legitimately* do is let the *user* decide what RGB working space to use to composite the images.

If you try to *dictate* the RGB working space for compositing the user's images, you are making a great big fat HUGE mistake. In fact you are making *exactly* the same mistake as forcing editing of UserRGB data to be done using sRGB chromaticities, except in cases where the *user* really intends the data to be sRGB data.

To repeat an earlier remark on one of the other points, there is no lists to maintain of which operations operate with what representation – this is local to the ops. Each individual operation within its own code specifies the data representation of input and output data in its own implementation.

If each developer decides on his own whether to use unbounded sRGB chromaticities for any given operation, together the developers are creating an ad hoc list. Playing with semantics to make it sound like "there is no list" is not helpful. It's just throwing chaff into the air.

Could you *please* abandon the entirely misguided notion of forcing UserRGB data to be edited using sRGB chromaticities or any other chromaticities not of the user's choosing?

>

/pippin

Elle

Simon Budig
2014-11-19 23:13:56 UTC (over 3 years ago)

Time to fork BABL and GEGL

Hi Elle.

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

Whether to *ever* use unbounded sRGB chromaticities to perform edits on UserRGB data is NOT AN IMPLEMENTATION DETAIL.

Unbounded sRGB is a mistake, pure and simple, *unless* the data is intended by the USER to be HDR sRGB data.

It really is not about editing. Even when for some reason the data in the graph is present as unbounded sRGB data the multiplication op will request the data as userRGB which will result in a transform, the op will get the colors in the desired space.

In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results.

I think you are missing that "unbounded" also allows *negative* R, G or B coordinates. That makes the colors imaginary in the sRGB color space, but it still is possible to convert them to all other RGB color spaces.

Unbounded sRGB can express all the colors XYZ can express. Transformations from userRGB to sRGB to userRGB are lossless.

Bye, Simon

simon@budig.de              http://simon.budig.de/
Jon Nordby
2014-11-19 23:20:02 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 19 November 2014 23:57, Elle Stone wrote:

In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results.

Doesn't this contradict with the following, from your recent mail? (I don't know what particularly is the definition of HDR used)

"We've also agreed that for chromaticity independent RGB editing operations ("CI ops", for short), by definition the same colors (as located in the XYZ reference color space) are obtained regardless of the chromaticities that are used to encode the data."

Jon Nordby - www.jonnor.com
Simon Budig
2014-11-20 03:47:49 UTC (over 3 years ago)

Time to fork BABL and GEGL

Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :)

Simon Budig (simon@budig.de) wrote:

I think you are missing that "unbounded" also allows *negative* R, G or B coordinates. That makes the colors imaginary in the sRGB color space, but it still is possible to convert them to all other RGB color spaces.

Unbounded sRGB can express all the colors XYZ can express. Transformations from userRGB to sRGB to userRGB are lossless.

The normal sighted human eye contains three types of cones which respond differently to a given light spectra. In 1931 researchers have tried to map the response of these cone types by having people stare at projection screens and match colors. The results of these experiments were combined and resulted in the definition of a "CIE standard observer", with the most important aspect being functions describing the "standard" response of the three cone types to light wavelengths: http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg

The "Tristimulus values" X, Y, Z refer to the three cone types. They can be determined by weighting the spectral power distribution with the resp. response curve and then computing the integral over the wavelength range from 380 to 780nm.

Related to XYZ is "xy", which simply is the color information normalized to a given intensity: x = X/(X+Y+Z) and y=Y/(X+Y+Z).

The horseshoe-diagram you see frequently when colors are discussed (http://en.wikipedia.org/wiki/File:CIE1931xy_blank.svg ) lives in the "xy" plane.

Note that these are absolute colors we're talking about here. For a given spectral power distribution we end up with certain XYZ values. This totally ignores other aspects of the human vision system. In particular knowing the XYZ coordinate of a color does not help at all in determining if something is perceived as "white". This is where the "whitepoint" becomes relevant. For example if you look at a piece of letter paper lighted by candle light you perceive it as white, since your eye is trained to take the color of the environment light source into account. Also experiences are relevant as well. You just assume that this piece of paper is white, since this is what you are used to and then your vision system takes this as a reference point.

If you'd see the same XYZ color in a daylight context, you'd probably be surprised how reddish yellow it actually is. Taking a photo of a candlelight scene with a digital camera set to a "daylight" whitepoint will give you an idea. No, the yellow color is not the camera lying to you, it is the eye not being allowed to lie to you.

Another important aspect of the XYZ system is, that it contains "imaginary colors": Color coordinates where it is impossible to create light spectra for. If you look at the color matching functions referenced above you see why: they do have huge overlaps, most wavelengths trigger two or even all three of the cone types simultaneously. Looked at it from the math point of view that means for example that "if Y is nonzero, then X or Z will be nonzero as well".

The XYZ coordinate (0, 1, 0) is an imaginary color. It is impossible to construct a real world light spectrum that results in this XYZ coordinate. Pure light with about 520nm wavelengh might get you close, but you still have X and Z components > 0. The rounded boundary in the horseshoe diagram represents the pure wavelengths and the weird shape is determined by the overlaps in the color matching functions.

XYZ is very useful in that it is a good tool to describe absolute colors and it is a superset of all the color impressions the "CIE standard observer" can perceive. It is the "safe bet" of color spaces.

However, since "pure X", "pure Y" and "pure Z" are basically a physical impossibility they cannot be used to build real world computer monitors. It has turned out that variants of Red/Green/Blue are a useful compromise to compose color impressions. The Phosphors used in CRTs and the filters used in LCDs have a specific spectral distribution and can be varied in their intensity, resulting in an absolute XYZ coordinate. In the real world we have a maximum brightness for each of the components and reducing the intensity moves the XYZ coordinate on a straight line towards (0,0,0), i.e. black.

Since the integral math behaves additively the three independent components construct a skewed cube in the XYZ color space. This is the "gamut": the range of color impressions that can be shown with this particular monitor. If you now normalize the intensities of the coordinates within this skewed cube you end up with a triangle in the xy-space, which is useful to describe the range of colors available to you with a given set of base colors: http://en.wikipedia.org/wiki/File:CIE1931xy_gamut_comparison.svg

The corners of the triangle are the xy-coordinates of the phosphors/filters used. These are the "primaries" or "chromaticities" of the given RGB space. (Note that ProPhotoRGB uses primaries which are imaginary colors. There never will be a computer monitor using ProPhotoRGB primaries.)

The triangle shape is no random accident: It is the convex hull of the three primaries: the points within are a weighted sum of the three corners, where the sum of the weights = 1.

Since physics does not allow for "subtracting" color spectra from each other we cannot escape from this triangle to display more colors. This is where the sRGB color space has severe problems representing color impressions with intense and pure colors which are perfectly within the realm of the real world. Using sRGB primaries to additively construct your color will impose harsh limits on you.

...that is if you are concerned about the real world implementation in a computer monitor.

When we talk about "unbounded" sRGB in the Gegl/Babl context we do away with this restrictions: We allow absurdly high intensities way beyond the physical capabilities of a specific light source. And we allow for negative intensities.

Yes, negative intensities are 100% absurd and wrong when you think about them in terms of implementing computer monitors.

However, we don't need to model a real computer monitor. We are not bound to the laws of physics when dealing with pixels in memory.

Allowing negative coefficients for the RGB values makes it possible to escape the dreaded gamut triangle. In fact this makes the unbounded sRGB color space as expressive as AdobeRGB, ProPhotoRGB and XYZ.

To reiterate: Every XYZ coordinate can be represented in the terms of sRGB primaries.

For example:

The Green Primary of the AdobeRGB 1998 colorspace is - specified with its own primaries - at the coordinates (0, 1, 0) (which is somewhat obvious).

Using e.g. the slightly convoluted color calculator at http://www.brucelindbloom.com/ we can convert this to XYZ = ( 0.185554, 0.627349, 0.070687 ).

(Note that there is a normalization involved here: AdobeRGB (1, 1, 1) is converted to an XYZ value scaled to Y = 1.0. We also get the xy coordinate of the green point here: xy = (0.21, 0.71) )

This in turn translated into unbounded linear sRGB yields:

sRGB = (-0.398283, 1.0, -0.042939)

And thats it. The color represented by (0,1,0) in AdobeRGB is equivalent to the color represented by (-0.40, 1.0, -0.04) in unbounded linear sRGB ("bablRGB"). Yes, there are negative coefficients, no, we don't need to worry about them.

And we can use the same math in reverse to reconstruct the AdobeRGB value to use it as userRGB for our multiplication operation. We end up at RGB=(0,1,0) where we started.

Note that there is nothing special about the sRGB that makes this possible. The same math would work with any other primaries, as long as they don't form a line in the xy diagram (i.e. they need to be linearily independant in XYZ).

However, for this to work we absolutely must not clamp negative values to zero. As soon as we do that huge errors will be introduced.

Gegl/Babl don't - at least not for the float types. We're sane there.

If anybody wants to dive deeper into that topic: Browse Bruce Lindblooms site. It has tons of valuable ressources, gives you formulae for various conversions and gives a lot of great insights.

I hope this helps, Simon

simon@budig.de              http://simon.budig.de/
Gary Aitken
2014-11-20 08:45:11 UTC (over 3 years ago)

Time to fork BABL and GEGL

First, in spite of the intensity of this discussion, I appreciate it. Thanks to all contributors for your efforts to make it clear.

A simple question, which may have been answered already and I may have missed (if so, a pointer will do).

What is the advantage of using unbounded sRGB instead of user RGB, *presuming* user RGB is not sRGB, and ignoring assumptions any outside software may be making about colorspace?

I'm having a great deal of difficulty understanding why one would choose to use a pipeline which by definition is going to require conversions when the user is using anything except sRGB. Both from a potential loss / distortion of data perspective and from a simple performance perspective.

As people become more comfortable with different colorspaces, and as they become more comfortable dealing with individual color channels, more and more work will be done using them. Particularly as device prices keep coming down and capabilities going up.

I can understand how / why one might wish to work in unbounded sRGB as an interim step towards a goal of working in user RGB *if* doing so gets significant results considerably faster than would otherwise be possible; and if doing so does not result in a lot of effort which will be discarded at the next step. But I have difficulty understanding why it would be the final design goal. The final design goal should be to get it right. If one were starting from scratch, would one choose to use unbounded sRGB?

I've personally made this mistake once and it resulted in the death of a good product. I also worked for a company which made this mistake and it cost them a year of (re)development when technology caught up with their assumptions.

Gary

Elle Stone
2014-11-20 09:30:00 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/19/2014 06:13 PM, Simon Budig wrote:

Hi Elle.

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results.

I think you are missing that "unbounded" also allows *negative* R, G or B coordinates. That makes the colors imaginary in the sRGB color space, but it still is possible to convert them to all other RGB color spaces.

No I am not missing anything.

When you convert from a wider gamut color space to unbounded sRGB, the out of gamut colors are expressed using at least one and perhaps two negative channel values.

When you edit HDR scene-referred images, the RGB channel values can be greater than 1.0. They never go negative unless the user chooses to do something odd like subtract red from black.

HDR scene-referred data is bounded by the xy coordinates of the RGB working space chromaticities.

Unbounded sRGB isn't bounded by anything.

See

"Models for image editing: Display-referred and scene-referred" http://ninedegreesbelow.com/photography/display-referred-scene-referred.html

Unbounded sRGB can express all the colors XYZ can express.

Of course it can.

Transformations from userRGB to sRGB to userRGB are lossless.

Of course they are lossless, to the limits of the precision used to do the conversion.

Please read the article I just linked to above. And then read this article:

LCMS2 Unbounded ICC Profile Conversions http://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html

There is a great big huge difference between HDR scene-referred and unbounded sRGB that none of you seem to understand. But you really do need to understand the difference between scene-referred and unbounded sRGB. That difference really does matter.

Elle

Elle Stone
2014-11-20 09:34:46 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/19/2014 06:20 PM, Jon Nordby wrote:

On 19 November 2014 23:57, Elle Stone > wrote:

In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results.

Doesn't this contradict with the following, from your recent mail? (I don't know what particularly is the definition of HDR used)

"We've also agreed that for chromaticity independent RGB editing operations ("CI ops", for short), by definition the same colors (as located in the XYZ reference color space) are obtained regardless of the chromaticities that are used to encode the data."

If you choose to do CI ops using sRGB chromaticities instead of UserRGB chromaticities, and you make a mistake about whether the op really is a CI op instead of the CD op, editing results are wrong. This is the crux of why you shouldn't do something so incredibly unnecessary as to convert UserRGB to unbounded sRGB to do the editing op.

Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do a little reading and try to understand what you are talking about, this whole conversation could have been over a long time ago.

Read these two articles. Then read them again.

http://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html

http://ninedegreesbelow.com/photography/display-referred-scene-referred.html

Elle

Elle Stone
2014-11-20 09:42:46 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/19/2014 10:47 PM, Simon Budig wrote:

Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :)

Most of what you said is exactly right.

When we talk about "unbounded" sRGB in the Gegl/Babl context we do away with this restrictions: We allow absurdly high intensities way beyond the physical capabilities of a specific light source. And we allow for negative intensities.

Yes, negative intensities are 100% absurd and wrong when you think about them in terms of implementing computer monitors.

However, we don't need to model a real computer monitor. We are not bound to the laws of physics when dealing with pixels in memory.

Allowing negative coefficients for the RGB values makes it possible to escape the dreaded gamut triangle. In fact this makes the unbounded sRGB color space as expressive as AdobeRGB, ProPhotoRGB and XYZ.

To reiterate: Every XYZ coordinate can be represented in the terms of sRGB primaries.

Above is exactly true. You can DISPLAY and STORE all colors using the sRGB chromaticities.

What you can't do is EDIT using sRGB as a universal RGB working space.

I'm not going to rehearse all the problems that are caused by trying to force EDITING to be done using the sRGB chromaticities.

See this article and follow the links and keep reading because I'm getting tired of repeating myself:

Using unbounded sRGB as a universal color space for image editing is a really bad idea

http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html

You can DISPLAY and STORE all colors using sRGB chromaticities. But EDITING is a different matter.

For example:

The Green Primary of the AdobeRGB 1998 colorspace is - specified with its own primaries - at the coordinates (0, 1, 0) (which is somewhat obvious).

Using e.g. the slightly convoluted color calculator at http://www.brucelindbloom.com/ we can convert this to XYZ = ( 0.185554, 0.627349, 0.070687 ).

(Note that there is a normalization involved here: AdobeRGB (1, 1, 1) is converted to an XYZ value scaled to Y = 1.0. We also get the xy coordinate of the green point here: xy = (0.21, 0.71) )

This in turn translated into unbounded linear sRGB yields:

sRGB = (-0.398283, 1.0, -0.042939)

And thats it. The color represented by (0,1,0) in AdobeRGB is equivalent to the color represented by (-0.40, 1.0, -0.04) in unbounded linear sRGB ("bablRGB"). Yes, there are negative coefficients, no, we don't need to worry about them.

And we can use the same math in reverse to reconstruct the AdobeRGB value to use it as userRGB for our multiplication operation. We end up at RGB=(0,1,0) where we started.

Note that there is nothing special about the sRGB that makes this possible. The same math would work with any other primaries, as long as they don't form a line in the xy diagram (i.e. they need to be linearily independant in XYZ).

However, for this to work we absolutely must not clamp negative values to zero. As soon as we do that huge errors will be introduced.

Yes, all of the above is true. I've said the same myself. In fact I've written articles on the topic.

Again, EDITING is different from STORING and DISPLAYING.

Elle

Mikael Magnusson
2014-11-20 10:13:27 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Thu, Nov 20, 2014 at 10:42 AM, Elle Stone wrote:

On 11/19/2014 10:47 PM, Simon Budig wrote:

Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :)

Most of what you said is exactly right.

To reiterate: Every XYZ coordinate can be represented in the terms of sRGB primaries.

Above is exactly true. You can DISPLAY and STORE all colors using the sRGB chromaticities.

What you can't do is EDIT using sRGB as a universal RGB working space.

I'm not going to rehearse all the problems that are caused by trying to force EDITING to be done using the sRGB chromaticities.

You can DISPLAY and STORE all colors using sRGB chromaticities. But EDITING is a different matter.

Yes, all of the above is true. I've said the same myself. In fact I've written articles on the topic.

Again, EDITING is different from STORING and DISPLAYING.

Then why have you argued against everyone trying to explain this to you?

Mikael Magnusson
Øyvind Kolås
2014-11-20 10:17:20 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Thu, Nov 20, 2014 at 9:42 AM, Elle Stone wrote:

Using unbounded sRGB as a universal color space for image editing is a really bad idea

There has been no plan for using unbounded sRGB as a universal color space in GEGL, not since the introduction of a target-space in April in the plans, these days called userRGB in the discussion.

The roadmap is a plan for how to achieve these things as smoothly and with as little unexpected work as possible. If someone has been working on the babl part of that roadmap and have a version of babl with the planned capabilities (I don't). It would be possible to use that new babl with current GEGL without the behavior of GEGL changing. Then the GEGL side of the work will start, first moving defintely chromaticity dependent ops to userRGB, as well as some chromaticity independent ops, it is also likely that *some* operations/tasks continue using the PCS, which is also a linear RGB, the user of an application like GIMP would neither know or be affected – this is what we are stating will be an implementation detail.

The roadmap as planned is a roadmap for babl, which includes some bits about changes in GEGL. The changes in GIMP, following things changing in babl and GEGL are, like the details of decisions we will be making in the GEGL stages, out of scope for planning how we add the needed capabilities to babl.

/pippin

Elle Stone
2014-11-20 10:19:25 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/20/2014 05:13 AM, Mikael Magnusson wrote:

On Thu, Nov 20, 2014 at 10:42 AM, Elle Stone wrote:

On 11/19/2014 10:47 PM, Simon Budig wrote:

Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :)

Most of what you said is exactly right.

To reiterate: Every XYZ coordinate can be represented in the terms of sRGB primaries.

Above is exactly true. You can DISPLAY and STORE all colors using the sRGB chromaticities.

What you can't do is EDIT using sRGB as a universal RGB working space.

I'm not going to rehearse all the problems that are caused by trying to force EDITING to be done using the sRGB chromaticities.

You can DISPLAY and STORE all colors using sRGB chromaticities. But EDITING is a different matter.

Yes, all of the above is true. I've said the same myself. In fact I've written articles on the topic.

Again, EDITING is different from STORING and DISPLAYING.

Then why have you argued against everyone trying to explain this to you?

Umm, what are you talking about?

I'm not being sarcastic. I don't understand what you are trying to say.

Do you think I am arguing in favor of unbounded sRGB image editing?

What is it that you think I am missing?

Elle

Elle Stone
2014-11-20 11:21:51 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/20/2014 05:17 AM, Øyvind Kolås wrote:

On Thu, Nov 20, 2014 at 9:42 AM, Elle Stone wrote:

Using unbounded sRGB as a universal color space for image editing is a really bad idea

There has been no plan for using unbounded sRGB as a universal color space in GEGL, not since the introduction of a target-space in April in the plans, these days called userRGB in the discussion.

Yes, you are correct. In April we did agree that some editing operations might require being done in the target space, now called UserRGB.

Thankfully we have moved on to the question of whether *any* UserRGB editing ops should be done using sRGB chromaticities.

My article "Using unbounded sRGB as a universal color space for image editing is a really bad idea" isn't aimed specifically at GIMP. It's aimed at the notion of using a universal RGB working space.

Other software developers besides babl/GEGL/GIMP have contemplated using unbounded sRGB for all editing.

Some of the VFX people contemplated using ACES as a universal RGB working space. One look at multiplication and they gave that up.

Lightroom uses ProPhotoRGB as a universal RGB working space. Some of the free/libre raw processors also use ProPhotoRGB as a universal RGB working space. Adobe would like everyone to think ProPhotoRGB is the ultimate RGB working space for interpolated camera raw files, but that's just not true.

The roadmap is a plan for how to achieve these things as smoothly and with as little unexpected work as possible. If someone has been working on the babl part of that roadmap and have a version of babl with the planned capabilities (I don't). It would be possible to use that new babl with current GEGL without the behavior of GEGL changing. Then the GEGL side of the work will start, first moving defintely chromaticity dependent ops to userRGB, as well as some chromaticity independent ops,

If babl formats for UserRGB are defined and made available to GEGL to use, then there is no rational reason for *any* GEGL/GIMP RGB editing operations to use sRGB chromaticities instead of UserRGB chromaticities. Just do a wholesale find and replace and be done with it. That way there are no unnecessary transforms to the sRGB chromaticities and there's no chance that the developers will decide "operation X" is chromaticity independent when really it's chromaticity dependent.

The only complication with "find and replace" is the handful of "can't be generalized" editing operations, plus whatever device-based code you want to keep around.

All such color-space-specific code needs to be labelled in the GIMP UI so the user doesn't use the op without understanding what they are getting into. Right now GIMP users can merrily use NTSC-based and sRGB device-based editing operations regardless of what color space they are really in, with no UI notification.

I tried to locate all such code to help make fixing the problem of color-space-specific code easier:
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html

it is also likely that *some* operations/tasks continue using the PCS, which is also a linear RGB,

If you want to convert from UserRGB to XYZ to unbounded sRGB to XYZ to LAB, etc, because for whatever reason it might be more efficient to concantenate and store a UserRGB to sRGB transform than to generalize the code that converts from UserRGB to XYZ and on LAB, that's not going to cause any problems. But the distinction between device-based sRGB and ICC profile illuminant-adapted sRGB does need to be reflected in the babl code.

the user of an
application like GIMP would neither know or be affected – this is what we are stating will be an implementation detail.

The user will be affected if the devs mistakenly decide that a chromaticity dependent RGB op really is a chromaticity independent RGB op. And the devs will need to add new code that deals with complications caused by extraneous and unnecessary conversions to unbounded sRGB and back.

There's no reason to saddle the devs with trying to make this kind of coding distinction, when the CI and CD ops can both be done using UserRGB chromaticities.

The roadmap as planned is a roadmap for babl, which includes some bits about changes in GEGL. The changes in GIMP, following things changing in babl and GEGL are, like the details of decisions we will be making in the GEGL stages, out of scope for planning how we add the needed capabilities to babl.

The babl functions that use Y to paint on a mask and to make grayscale masks really do need to be generalized to use UserRGB Y, or else there needs to be side by side functions. Otherwise GIMP layer masks will only be correct for sRGB images.

/pippin

Elle

Elle Stone
2014-11-20 11:53:23 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/20/2014 04:34 AM, Elle Stone wrote:

Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do a little reading and try to understand what you are talking about, this whole conversation could have been over a long time ago.

This came out a great deal more "snippy" than I intended it to be and I apologize.

Elle

Elle Stone
2014-11-21 14:05:40 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/20/2014 06:53 AM, Elle Stone wrote:

On 11/20/2014 04:34 AM, Elle Stone wrote:

Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do a little reading and try to understand what you are talking about, this whole conversation could have been over a long time ago.

This came out a great deal more "snippy" than I intended it to be and I apologize.

Elle

Again, my apologies for being snippy. Hopefully I haven't bored you all to tears trying to explain problems with editing in the unbounded sRGB color space.

For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one.

GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management.

Elle

Alexandre Prokoudine
2014-11-21 14:06:04 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Fri, Nov 21, 2014 at 5:05 PM, Elle Stone wrote:

For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one.

GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management.

Please keep the invitation to LGM2015 in mind, though :)

Alex

Øyvind Kolås
2014-11-21 14:43:17 UTC (over 3 years ago)

Time to fork BABL and GEGL

On Fri, Nov 21, 2014 at 2:05 PM, Elle Stone wrote:

Again, my apologies for being snippy. Hopefully I haven't bored you all to tears trying to explain problems with editing in the unbounded sRGB color space.

For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one.

GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management.

Based on some of the last few exchanges it seems like you are in almost complete agreement with the babl part of the "babl roadmap", and only disagree on some of the direction GEGL should be taking once the babl roadmap has been implemented, and the results of added capabilities to babl start propagating through GEGL and GIMP. We've spent much energy discussing the future instead of making it happen. I hope you've got the energy to continue help us in more productive ways once we've got more of those plans in place.

/pippin

Elle Stone
2014-11-21 14:55:39 UTC (over 3 years ago)

Time to fork BABL and GEGL

On 11/21/2014 09:43 AM, Øyvind Kolås wrote:

On Fri, Nov 21, 2014 at 2:05 PM, Elle Stone wrote:

Again, my apologies for being snippy. Hopefully I haven't bored you all to tears trying to explain problems with editing in the unbounded sRGB color space.

For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one.

GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management.

Based on some of the last few exchanges it seems like you are in almost complete agreement with the babl part of the "babl roadmap", and only disagree on some of the direction GEGL should be taking once the babl roadmap has been implemented, and the results of added capabilities to babl start propagating through GEGL and GIMP. We've spent much energy discussing the future instead of making it happen. I hope you've got the energy to continue help us in more productive ways once we've got more of those plans in place.

/pippin

Once things are in place, I would love to continue working towards improving GIMP color management. Hopefully by the time spring rolls around those "time constraints" I mentioned might have loosened up a bit.

As to whether or how much the discussions in the last month have been productive, well, that's a point on which there would be probably be considerable disagreement.

Best regards, Elle