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

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:

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:

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]