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

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.


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