> Please provide a specific example of an actual CMM in an ICC profile > workflow that doesn't use XYZ for converting between RGB working spaces. Please read simons post about matrix multiplication, in his camera example the data never exists as XYZ. > You falsely assume that 8-bit images are always sRGB images and that 16-bit > integer images are probably sRGB images. This is not being assumed, but it is a matter of fact that a lot of buffers are in these formats and we want to deal well with them. >> formats are crucical for integrating with existing file formats and >> libraries; > > File formats that only work with sRGB images should not impact color-managed > image editing. Advise the user to convert to sRGB. The data needs to be loaded into a GeglBuffer with a BablFormat that uniqely describes the color content. For 8bit sRGB with babl that has traditionally been "R'G'B' u8", in the roadmap in babl I even suggested that the buffers data is loaded into should be changed to be "sRGB:R'G'B' u8" for clarity even if it will continue to mean the same as "R'G'B' u8". And the chromaticity/working/target space should also be set to "sRGB:R'G'B'". > Unbounded linear gamma sRGB is not a Profile Connection Space. > > Idiosyncratic redefinitions of well-established color management terms > confuses people who don't understand ICC profile color management. > > Idiosyncratic redefinitions of well-established color management terms makes > it difficult for people who do understand ICC profile color management to > communicate with the babl/GEGL devs. There are differences between the internal implementation of a system and the public API. Calling the bablRGB a PCS, since that is the role it has in the internal implementation was an attempt at making you understand the architecture, and I guessed you did understand since you have been using the term as well. I thought you would understand how XYZ fills the same role in ICC. It is never called either XYZ nor PCS in the babl code. It is better if we call it bablRGB than linear sRGB which is an oxymoron. > Is there any point in my demonstrating how convoluted and unworkable it will > be to convert to unbounded sRGB whenever Y is involved? Because if there > isn't, I don't want to waste my time. > > For a moment it seemed that perhaps unbounded sRGB was going to be dropped > and we could move on to generalizing the code to use Y and XYZ taken from > the user's chosen RGB working space > (http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html). I was hinting at how a given set of chromaticities wouldn't be affecting single babl formats but change interpretation of also other formats when given a prefix. You seem to challenge mention of sRGB to the extent that people have been championing linear workflows. While bablRGB will end up being an implementation detail that is an optimization. Babl will end up having _many_ different RGB spaces with associated grayscale format; at some point probably also associated non-linear spaces but that will have lower priority. Among these spaces will be a space called sRGB which behaves like the unprefixed formats. When we have these spaces. When we have these additional spaces - what I have suggested is that we then mark the operations which _are_ chromaticity dependent to operate in this space. I have also hinted at what we might want to do, or at least which things would be possible to do - including getting rid of all unprefixed formats, as well as the possibility that such things could be decided dynamically. There is a lot of code in GIMP that we intend to keep working as we move forward, the only way is by small incremental changes while keeping things working, changing as few assumptions as possible as move move along. /Ø _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
