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

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

On Thu, Oct 9, 2014 at 6:27 PM, Michael Henning
<drawoc darkrefraction com> wrote:
> > > But the "R'G'B'A
> > > u8" and u16 and similar better be left alone because they have been
> > > written with the assumption that their data is sRGB
> >
> > If there is code for 8-bit and 16-bit integer images that uses sRGB
> > *primaries*, that code needs to be rewritten or removed. It makes no sense
> > in the context of a high end, high bit depth image editor.
>
> I think this was a little confusing. Øyvind seems to be talking about
> the large quality loss that's inherent in converting between different
> color spaces while using 8 or 16-bit integers. Personally, I think we
> should have the capability of having integer data in different working
> spaces, and there's no technical reason why that's impossible.

I am referring to the places in the code that is explicitly using the
8bpc or 16bpc "R'G'B.." formats. These are likely integration points
with other systems/libraries that in their api/format/data exchange
contract always should be interpreted as 8bit sRGB; like many file
formats both in use and legacy. I added some architecture notes and a
small write up of the plans as they relate to babl in the git repo;
where I elaborate how we can move forward with managing pixel/formats
and color spaces.

/Øyvind