On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone <l.elle.stone@xxxxxxxxx> wrote: > So gathering the gist of this discussion, it would be useful to add > the code for 16-bit floating point and 32-bit integer to the lcms > plug-in? > > And presumably if/when the lcms.c plug-in disappears, this particular > code could be transferred over (suitably modified, of course) to > whatever takes its place? I do not know the details of GIMP, but if the icc conversion handling moves into the GIMP core rather than a plug-in a lot of the code can be kept. Maybe what makes most sense is turning the logic of these transformations into GEGL operations, (that could be called by the GIMP core, or be re-used also outside GIMP). This way we might also make the generic image loader in GEGL responsible for inserting color conversion operations for its internal graph.). Turning the core-logic of the lcms.c plug-in into gegl-ops should be possible in such a way that at first GIMPs way of invoking the lcms plug-in continues working while the lcms plug-in uses the graph API of GEGL rather than directly operating on GeglBuffers. Creating custom babl formats for specific ICC profiles is possible, and would take a similar form to how babl/GEGL/GIMP currently deals with indexed images. With such an option the lcms code would move into a babl extension or become part of babl - this might be within the scope of babl, but I do like it's scope smaller striving to mostly do conversions between different pixel layouts and well defined color representations. > Where can I find the proper babl type for 16-bit floating point and > 32-bit integer? And what are the corresponding gegl iterator babl > formats for images with and without alpha channels? Is there a list > somewhere? If you click "Pixel formats" here http://gegl.org/babl/#Vocabulary you should get a list of the pixel formats babl has built in. The way these formats are expressed are rather consistent; though I do see that there could be some improvements to the documentation of how to manually decode a format string. >>Going forward, AFAIK, the "image->mode->assign/convert color profile" >>menu entries should be removed from the lcms plugin, and everything >>automatically converted to srgb/R'G'B' on import. > > Automatically converting an image to (extended) sRGB if it had the > wrong embedded profile would mean the image now has the wrong colors. > Likewise with automatically assigning sRGB to an image that doesn't > have an embedded profile, unless the image really is an sRGB image. > > Also, presumably upon export you still need to give the user the > option to export to a color space other than sRGB. The only time I > use sRGB as an output space is when preparing an image for the web. Yep, what most people consider working-space in other applications would become an "target-space" this would be the desired color space and gamut, soft-proofing, out-of-gamut indications etc. should be working with the knowledge of the gamut of this space. The mechanics of defaults for this target-space, based on imported images or preferred own defaults needs to be considered from a UX point of view. > Presumably converting an image to the "extended" sRGB color space > won't clip, for example, the colors in a ProPhoto image or an image > that is still in the camera input space. But exporting the image as > pure regular sRGB certainly could (and very often would) clip colors. Yep, which is why when the display-filters of GIMP is revisited and turned into a chain of GEGL ops, we need to look into gamut warnings and soft-proofing taking the target-profile into account. /Ø -- _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
