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

[Øyvind Kolås <pippin gimp org>]

On Fri, Aug 31, 2012 at 12:30 AM, Øyvind Kolås <pippin gimp org> wrote:
>> In point of fact the extended scRGB does NOT cover all of the
>> ProPhotoRGB color space or the CIE 1931 color space. scRGB leaves out
>> a good chunk of the all-important greens.
>
>> Quoting from Wikipedia, which has a very nice picture that everyone
>> ought to go take a look at: http://en.wikipedia.org/wiki/ScRGB
>>
>> "Negative numbers enables scRGB to encompass most of the CIE 1931
>> color space while maintaining simplicity and backward compatibility
>> with sRGB ***without the complexity of color management***. The cost
>> of maintaining compatibility with sRGB is that approximately 80% of
>> the scRGB color space consists of imaginary colors."
>>
>> The point of scRGB is MicroSoft's and Hewlett-Packard's attempt to yet
>> again not deal with color management. But color management is part and
>> parcel of all high end image editors, and well-integrated with Linux.
>> So why on earth would any Linux image editor want to follow in the
>> MS/HP footsteps and use scRGB, with the attendant loss of ability to
>> represent all of the real world colors and the attendant requirement
>> of using very high bit depths to maintain image integrity?
>
> The "RGBA float" space of babl does not leave out greens, blues,
> purples or imaginary colors of any magnitude. The entirety of the
> tristrimulus gamuts expressable in any RGB triplet space can be
> expressed. (granted some parts of this 32bit floating point
> representation is not the most _useful_ real world colors, but no
> colors are being left out).

You should also note that babl's "RGBA float" format is not inspired
by or defined by scRGB, but could more well be described as a linear
light / physical color space, with the same RGB primaries as sRGB, a
linear gamma curve, white at 1.0, 1.0, 1.0 - black at 0,0,0 extendable
towards the limits of floating point representation negatively and
positively.

It has been pointed out to me that this in some way resembles some
aspect of scRGB - however I arrived at the behavior of the space
before I ever looked at anything that had to do with it. To do color
management properly - the important thing is to tag all your buffers
with the relevant color profile, a proliferation of "source data
profiles", "standard press profiles", "optimized 8bit working spaces"
and more does not help the user keep their colors under control,
instead it makes it easier to mis-configure your workflow/system.
Building a system around linear light instead of gamma encoded
processing; with strict coordination of the color spaces involved
should lead to more predictable control over results.

With the strict color management architecture of GEGL - you would lose
the memory gains from storing layer data in lower precision with
custom profiles in terms of additional conversions that would then be
necessary for when temporarily linearising data and increasing
precision for 32bit processing (and back again to destructively store
the new results). In the future when the system is in place; there is
the option to add direct 8bpc and 16bpc fast paths for sRGB processing
(as well as maybe add ugly hacks permitting the user to pretend that
the 8bit or 16bit data is not in sRGB but some other space; including
problems resulting from gamma problems then present when blurring,
scaling, compositing and more...) neither of those are something I'd
consider of importance until basics are covered.

/Ø
--