Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

Am 31.08.2012 18:27, schrieb Elle Stone:
The ultimate goal of working in a linear light color space is both
clear and noble.

I support this. Working in linear light color space has many advantages. One of them is the potential speed. The other would be tools that only need to work inside one color space.

The purpose of the constant background converting back and forth
between two tone curves, sRGB TRC and linear gamma, is not clear at

At the moment it is also not clear to me. But i guess that it has to do with all the legacy code that currently is in the way, because this parts haven't been rewritten. I assume that this parts just got a wrapper (it does the color conversion, currently every time) to be able to work on the core while not making everything unusable.

But if I'm wrong and it should stay like this, then this is a real problem.

"In service of the noble goal" doesn't explain *why* the conversions
are done over and over again instead of just once. I really, really,
really want to know why those relentlessly repeating background
conversions between sRGB TRC and linear gamma are happening. But I
will stop asking. And maybe some kind soul will send a private email
giving an explanation that I can understand.

In the case I'm not lier than i have given the explanation above.

I was excited to find out that the latest LCMS can do color
conversions involving negative floating point numbers. If the Gimp
code is only 20% finished, then perhaps the information I just gave
about the new ability of LCMS to do conversions involving negative
floating point numbers might be pertinent to crafting the remaining
80%. But if not, then I apologize for posting it.


Lets see what the developers have in mind. If they do it right, then there should be two solutions with the empowered to choose which one he likes, because both have a distinct advantage and disadvantage:

A) The buffer of any type / color space will be converted at load/creation time to linear RGB float. Anything else works only with linear RGB float. Final output will be converted to sRGB or device color profile.

B) The buffer will be loaded and stored in native/original format. Every access to the buffer which is not linear RGB float will force a conversion, which might need caching for better speedup. The core still works entirely in linear RGB float. and the final output will be converted to sRGB or device color profile.

While (A) would be fast it is very memory intensive for larger images. The method (B) might be very slow in comparison, but it needs much less memory.

Ideally the user would load layers/buffers and would have the choice to convert the buffer to any color space/format he likes, with the hint that linear RGB float is the fastest that does not need any conversion. So the user would have to option if he wants speed or less memory consumption.

But maybe someone wants to enlighten me that both things are not mutually exclusive.


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