On Thu, Oct 9, 2014 at 6:27 PM, Michael Henning <drawoc@xxxxxxxxxxxxxxxxxx> 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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
