Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/09/2014 11:04 AM, scl wrote:
> I thought of the same (=a common) colour space for all ops, leading to a
> commonly shared pixel format which makes conversions unnecessary.

If I misunderstood what you just said, my apologies. But I think you've 
concluded that because sRGB is so small, therefore the out of gamut 
colors are the only problem with using sRGB as a universal color space.

That is not what I've been trying to explain. That's just an extreme and 
easily demonstrated problem with sRGB as a universal color space.

There is no such thing as a universal RGB color space suitable for 
editing all images, produced by all devices, for display on all devices, 
for all possible artistic intentions.

The problem with multiply is *not* just that multiplying out of gamut 
colors produces meaningless results.

The problem with multiply is also that performing multiply in different 
color spaces produces different results. The usefulness of the results 
in one RGB color space vs another RGB working space depends *entirely* 
on what the user wants to accomplish by multiplying colors together.

For instance, in Color space A, you can't use Levels to white balance 
away a color cast that was created in Color space B. It just can't be 
done: 
http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html 


Channel data is completely changed by converting from one set of 
primaries to another. Things you can do with channel data in one color 
space become entirely impossible after converting to another color 
space: 
http://ninedegreesbelow.com/photography/unbounded-srgb-channel-blend-convert-black-white.html

There is no universal color space.

Out of gamut colors are not the only problem.

ACES is not a universal color space, although it mitigates the problem 
of out of gamut colors.

The Identity color space, which I did mention a couple of years ago, is 
not a universal color space, although it mitigates the problem of out of 
gamut colors.

I say mitigates, not solves, as cameras have a nasty habit of not 
reproducing colors exactly the way people see them. Saturated yellows 
can be out of gamut as interpreted by camera matrix input profiles.

You have to consider the source of the data, what devices the data will 
eventually be displayed on, and the artist's reasons for manipulating it.

Compositing data from different sources together as one image is the 
very *last* step in a well-defined, carefully thought out workflow. 
First you do whatever needs to be done in the source color space(s) to 
get the colors the way you want them to be.

You can't code an image editor on the basis of making drag and drop 
easier. You have to convert the pixels from the source to the 
destination color space. Krita does it. Surely GIMP can do it too.

There is not and cannot be, a universal color space suitable for editing 
all images, for all artistic intentions.

> You and Elle are the right people to find that space and fine tune its
> implementation

There is no such space. Therefore you can't fine tune its 
implementation. It doesn't exist.

> and I hope you both are open enough to find a good
> solution together.

This has nothing to do with being open to finding a good solution together.

You can't base an image editor around making it easy to drag colors from 
one layer stack to another.

There is no universal color space suitable for all image editing tasks.

With respect,
Elle Stone