El lun, 17-11-2014 a las 23:41 +0100, Mikael Magnusson escribió: > The above two things are implementation details as Simon said. If you > don't understand this, then please don't write long articles full of > misinformation that get widely quoted. Your answers suggest you didn't > even understand what he said. Your argument is like saying it matters > if you store an integer in decimal or binary, and doing anything else > than the user input is definitely wrong, because there is no longer > any way to display it in this format. > > Gegl stores pixels in memory in some format, it knows what format it > used. Gimp can display/edit pixels in some color space (specified by > the user). Gimp asks Gegl for pixels saying what colorspace it wants. > Gegl presents the pixels to Gimp. All is well. It doesn't matter how > the pixels are stored. I think I have at this point a reasonable grasp of what's the plan here and that unbounded sRGB is intended a just one representation of the many possible with babl (and that its primary function is to be used as a PCS)- I also understand that chromaticity dependent operations will use userRGB. However, and this is what Elle is asking and nobody seems to understand, the question is if bablRGB is still going to be used as the RGB space for all the chromaticity independent operations and if that's a yes, then WHY. Is it just to spare one single matrix transform in case the buffer is not available in userRGB? And yes, jonnor said something that seems to contradict pippin if that's the case: in the future RGB operations that now ask for bablRGB should ask for userRGB instead. That of course doesn't take bablRGB out of the picture (it would still would be used as PCS), but means specifically that operations won't be fed anymore with unbounded sRGB but user defined RGB. When Elle says "converting to unbounded sRGB", she's referring to what babl will do when an operation requests for bablRGB. (We know it's not a forced conversion at the beginning of the pipe, and the GEGL tree can keep different representations for the buffer). If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available. Could you please address that question with a straight answer? Gez. _______________________________________________ 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
