"We won't provide any conclusions because the results in the given tests context are self explanatory."

This is another way to say: "Trying to put things in context so that the results are relevant to real life would expose us to criticism, so we'll say it's obvious so that other people get the dunce cap."

On 12 May 2015 at 23:21, Elle Stone wrote:

As the GIMP 2.10 release edges closer, I thought GIMP devs and GIMP users might want to look at the following article:

http://colour-science.org/blog_about_rgb_colourspace_models_performance.php

Of 29 compared RGB working spaces, sRGB came in second-worst in a comparison of performance against spectral reference. AdobeRGB1998 ranked 15th from the top, ProPhotoRGB 17th from the top.

BetaRGB came in at the very top. Of the larger gamut color spaces, Rec.2020 and two ACES variants were in the top ten.

Quoting the introduction to the article:

"The purpose of this document is to compare RGB colourspace models operations performance against spectral reference."

"Various mathematical operations because of the nature of matrices and linear algebra are dependent on given RGB colourspace primaries. The same operations performed in different RGB colourspaces will yield different tristimulus values once converted back to CIE XYZ colourspace. For example multiplication, division and power operations are RGB colourspace primaries dependent while addition and subtraction are not."

Quoting the conclusion: "We won't provide any conclusions because the results in the given tests context are self explanatory."

The study suggests that sRGB is just about the worst possible color space you could use for image editing.

Best regards, Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography _______________________________________________ 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

Am 13.05.2015 um 07:52 schrieb Nicolas Robidoux :

"We won't provide any conclusions because the results in the given tests context are self explanatory."

This is another way to say: "Trying to put things in context so that the results are relevant to real life would expose us to criticism, so we'll say it's obvious so that other people get the dunce cap."

No, the conclusion is quiet easy. And it’s what Elle says for, AFAIK, more than a year.

Results of operations on RGB data depend on the given RGB primaries and will differ with different RGB primaries. So, all operations on user RGB data should only use user RGB primaries and not sRGB primaries or any other RGB primaries chosen by developers.

Simone Karin

Simone Karin Lehmann (simone@lisanet.de) wrote:

No, the conclusion is quiet easy. And it’s what Elle says for, AFAIK, more than a year.

...and what the GIMP developers have accepted for more than a year.

Just for the records.

Bye, Simon

simon@budig.de              http://simon.budig.de/

El mié, 13-05-2015 a las 10:36 +0200, Simon Budig escribió:

Simone Karin Lehmann (simone@lisanet.de) wrote:

No, the conclusion is quiet easy. And it’s what Elle says for, AFAIK, more than a year.

...and what the GIMP developers have accepted for more than a year.

Just for the records.

(not arguing or trying to bring back the neverending thread, just asking "for the records")

What's the immediate plan for 2.10? It's still using unbounded sRGB for the working RGB pixel formats?
As it was already discussed, that would be enough for keeping things more or less consistent with earlier versions of GIMP (i.e. getting sRGB right) and fast, but potentially problematic when dealing chromaticity dependent operations and wider gamut colorspaces.

I've been told that the goal is to release 2.10 with GEGL providing the same functionalities and keeping the legacy appearance of legacy files as soon as possible and then take care of specific color management in future versions.
That seems a reasonable plan, of course, but I'm curious about how the program will deal with non-sRGB images if editing them in the source colorspace won't be possible and some operations are likely to fail with unbounded sRGB.
Forcing a bounded conversion to sRGB for the time being could be a solution, although quite unpopular for anyone using anything but sRGB.
Or is there still chances of an "anyRGB" pixelformat allowing working on the artist's colorspace of choice for 2.10?

Gez.