On 1/13/13, Michael Henning <drawoc@xxxxxxxxxxxxxxxxxx> wrote: > You misunderstood my idea. I don't want babl to get specific > conversions for different ICC profiles; I want a generic mechanism to > take any ICC profile and turn it into a babl format. Øyvind indicated > that this is similar to how indexed formats already work (take a > palette and turn it into a babl format), so this wouldn't need vast > amounts of new code. > Pippin's words were "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." I interpreted that to mean one custom babl format per specific ICC profile, but maybe I misunderstood Pippin. > Part of why I suggested this is because it seems much more elegant > than tagging a newly loaded image as, say R'G'B'A when the image is > actually something else, like the code does now. > I'm not sure what you mean. The existing Gimp lcms.c code queries the image to see what format it's in, then sends it down the appropriate code path. It only goes down the "R'G'B'A" path if it's an RGB image with an alpha channel. Certainly the code can be written more elegantly. In particular, as more color spaces are added in (as a first step, I've added in the ability to do transforms between one gray color space to another gray color space), the actual transformation code should be moved to a separate function in order to avoid repetition. But anyway you slice and dice it, there's a lot of code to write in order to give LMCS2 all the information needed to do an ICC color space conversion. On 1/13/13, Michael Henning <drawoc@xxxxxxxxxxxxxxxxxx> wrote: > The idea would be to write a babl extension that links to lcms (or a > similar lib), and uses that to do conversions under the hood. > I'm not sure what you mean by "under the hood". LCMS2 requires a lot of very specific input in order to do an ICC profile conversion: LCMS2 requires that you tell it the user-specified conversion intent and whether or not to use black point compensation (also specified by the user). There's also some additional CMYK "black preserving" options that the user might want to specify for CMYK images (which options are not currently available from the Gimp gui). LCMS2 requires that you tell it the actual source (usually Gimp reads this from the image itself) and destination (usually Gimp reads this from disk) ICC profiles. Those 34 tag types that Graeme refers to do matter when doing the profile conversion. This is especially true if you are using absolute conversion intent because the required information is stored and handled differently in V2 and V4 profiles. The new tags waiting in the wings also will matter if you want to attract the attention of the high-end image processing people. LMCS2 also requires that you tell it what LCMS2 format the image is in before and after the color conversion. The LCMS2 format depends on the image color space, whether the image has an alpha channel, how many channels total (eg n-color printing), how the channels are arranged (RGB, RBG, etc) and the precision (8-bit integer, 16-bit integer, 32-bit floating point, etc). You tell LCMS2 what format the image is in by specifying the LCMS2 "formatters", one for the input image and one for the output image (eg TYPE_RGB_16, TYPE_GRAY_HALF_FLT, etc). The latest version of LCMS2 has 10 predefined grayscale formatters, 28 predefined RGB formatters, 47 predefined CMYK formatters, several formatters each for XYZ, LAB, LUV, YUV, HSL, and HSV; one for indexed images, plus a separate set of formatters for each color space for floating point images. There's also an LCMS2 plugin for writing additional formatters if the one you need hasn't been written yet (unfortunately, a formatter hasn't been written for 32-bit integer images). The existing Gimp lcms.c code is made simpler by the fact that it only does conversions where the input and output color space use the same LCMS2 formatter (eg TYPE_RGB_16 to TYPE_RGB_16). But as soon as you add in converting from eg 16-bit integer grayscale input to 32-bit floating point RGB, or from 32-bit floating point RGB to 8-bit CMY(K) output, the code will get a lot more complicated. Kind regards, Elle Stone -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
