On Thu, Apr 17, 2014 at 5:49 PM, Nicolas Robidoux <nicolas.robidoux@xxxxxxxxx> wrote: > (Apologies if I am missing the point.) > > What Elle's excellent > http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.htmlsuggests > to me is that the designer of an operation should choose what > color space the operations should internally work in, and convert in and > out of it. No more and no less. My impression is that the GEGLized GIMP is > structured so that this is feasible without too much work on the operation > coder. The conceptual model for the coder is the same as if the images were converted to floating point XYZ on import; and converted to the coders choice of input and output pixelformats before and after. The smaller set of variation needed for the most frequently performed conversions makes things run faster; in particular since data isn't transformed back to XYZ but on demand changed to the next operations desired format instead of copying where a copy nevertheless would take place in the code. > I have made this point in another context: Downsample through linear light, > for example (unbounded) linear RGB with sRGB primaries or XYZ (unless > possibly your sampler is monotone or close to monotone). And preferable > upsample through a perceptual colorspace (like Lab or CMC or (unbounded) > sRGB). > > Elle's examples simply suggest that the "broken" operations do not > internally use a good choice of color space, and point to one better choice. The a building block missing for doing this in GEGL with the smallest effort (more effort on the programmer using GEGL) is two GEGL operations using lcms2 for converting to/from arbitrary ICC profiles. One would also want linear versions of the spaces defined by the ICC profile. These two operations would be placed around the steps with overriden working-space. I offer no opinion about how that would be done in the UI. A lower level integration could permit GEGL operation writers to specify wanting "import profile data"; perhaps linearised - the developer of the op could then even offer some choices up for the autogenerated property UI. Another way to see this list; is as a list of operations that to some degree were broken in GIMP-2.8. Where all operation happen in a globally dictated 8bpc working-space. Possibly sRGB. Most of these are things that should have happened in linear light but didn't. This is what the strong internal color management of annotating all buffers with the datas relation to linear light RGBA which is strictly defined in relation to XYZ fixes. The cleanup and deciding the most reasonably formats for each operation is a work in progress; parts of GIMPs UI surely could be improved in relation to values that currently are just preserved but not visible/actionable. /pippin _______________________________________________ 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
