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

[Tobias Oelgarte <tobias oelgarte googlemail com>]

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
> all.

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.
>
> Elle

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.

Tobias