lcms high bit depth update: now that it works, adding and improving functionality
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
lcms high bit depth update: now that it works, adding and improving functionality
On Wed, Nov 28, 2012 at 8:04 AM, Elle Stone wrote:
On Wed, Nov 28, 2012 at 4:11 AM, Tobias Jakobs wrote:
with all this changes and the recent work in git it looks very promising.
Thank you and every one from the Gimp Team who help for this work. Could you perhaps give us short status update about what is now working and what is still missing?
The modified lcms.c plug-in code is now in master. The lcms.c plug-in uses LCMS2 (as does the rest of Gimp from git, thanks to Mitch and Laurent Martelli)
I posted a list of proposed additions/enhancements to the lcms.c plugin and would like some feedback on what to start working on next ( http://ninedegreesbelow.com/temp/gimp-lcms-8.html). For instance,
*The code that displays information in the "Image Properties/Color Profile" box needs to be rewritten, and I'd like to know what information people would like to see in the box.
*V4 profiles allow internationalization, but I'm not sure how well it works in practice, so right now it is hard-coded to en and US.
*LCMS2 provides for error checking, but the documentation is opaque. It might help if I knew what kinds of errors users actually encounter in terms of faulty ICC profiles, etc.
*I haven't yet added in code that handles Gimp's 16-bit floating point and 32-bit integer image types. Are these image types being used by anyone?
*At present, the lcms.c plug-in only handles RGB images. I would like to add support for CMY(K), Gray-scale, LAB, and XYZ images. Are there any other higher priority candidates? Is there any reason why Gimp shouldn't be able to open LAB and XYZ images, at least to convert them to RGB and perhaps to convert them back when exporting? Also, I have almost no experience with CMYK and don't know how Gimp currently handles CMYK.
Kind regards, Elle Stone
lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 9:23 AM, Elle Stone wrote:
I posted a list of proposed additions/enhancements to the lcms.c plugin and would like some feedback on what to start working on next (http://ninedegreesbelow.com/temp/gimp-lcms-8.html). For instance,
*snip*
*I haven't yet added in code that handles Gimp's 16-bit floating point and 32-bit integer image types. Are these image types being used by anyone?
16bit integer can perhaps be useful for various scientific applications that GIMP thus far hasn't been well suited for. 16bit floating point however is useful and widely used in for instance movie production industry. It halves the storage/memory requirement compared to 32bit float and isn't much less precise.
*At present, the lcms.c plug-in only handles RGB images. I would like to add support for CMY(K), Gray-scale, LAB, and XYZ images. Are there any other higher priority candidates? Is there any reason why Gimp shouldn't be able to open LAB and XYZ images, at least to convert them to RGB and perhaps to convert them back when exporting? Also, I have almost no experience with CMYK and don't know how Gimp currently handles CMYK.
For 3 color component color models like LAB and XYZ what makes sense to do is to convert to linear light RGB in floating point. Given that GEGLs "RGB(A) float" format is unbounded doing this should not cause any clipping of "out of gamut" colors. CMYK is a different story, but a good start would be to convert CMYK to RGB on import, and keep track of the profile so that it can be reapplied on export. This is different from a native CMYK workflow, and the way we are trying to steer GIMP in the future is to consider CMYK printing a subset of any ink-based printing, thus CMYK is a special case of 4 inks on different plates.
/
lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 2:57 AM, yvind Kols wrote:
*I haven't yet added in code that handles Gimp's 16-bit floating point and 32-bit integer image types. Are these image types being used by anyone?
16bit integer can perhaps be useful for various scientific applications that GIMP thus far hasn't been well suited for.
Like FITS, for example.
Alexandre Prokoudine http://libregraphicsworld.org
lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 10:18 AM, Alexandre Prokoudine wrote:
On Thu, Nov 29, 2012 at 2:57 AM, yvind Kols wrote:
*I haven't yet added in code that handles Gimp's 16-bit floating point and 32-bit integer image types. Are these image types being used by anyone?
16bit integer can perhaps be useful for various scientific applications that GIMP thus far hasn't been well suited for.
Like FITS, for example.
I meant to say 32bit integer, but 16bit integer is also be useful for similar purposes :)
/
lcms high bit depth update: now that it works, adding and improving functionality
It is my opinion that XYZ is not fully replaced by infinite gamut linear RGB if only because XYZ has a channel which is a proper luminance channel. RGB does not.
Enough to deserve a place within GIMP? Don't know. If my (initial) inputs and (final) outputs are sRGB, linear RGB with sRGB primaries is a better all around choice. But not a full replacement when you use nonlinear filtering.
lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 10:36 AM, Nicolas Robidoux wrote:
It is my opinion that XYZ is not fully replaced by infinite gamut linear RGB if only because XYZ has a channel which is a proper luminance channel. RGB does not.
Enough to deserve a place within GIMP? Don't know. If my (initial) inputs and (final) outputs are sRGB, linear RGB with sRGB primaries is a better all around choice. But not a full replacement when you use nonlinear filtering.
Enough to deserve a place in babl/GEGL, but I think the ways they are going to be used (by image processing algorithms) is well enough covered without explicitly storing / confronting the user with an XYZ image mode.
/
lcms high bit depth update: now that it works, adding and improving functionality
As mitch and I discussed on irc, as the plan stands right now, the GIMP won't have any working color profile.
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.
I think the best design in the end would be for babl to eventually get icc profile support itself. Then different loader plugins could simply tag their data with a babl format created using the icc profile, and all the conversions would happen without a plugin stepping in.
-- drawoc
(yvind: Just to be sure - it's sane to store srgb data with the babl format R'G'B', right?)
On Wed, Nov 28, 2012 at 7:10 PM, yvind Kols wrote:
On Thu, Nov 29, 2012 at 10:36 AM, Nicolas Robidoux wrote:
It is my opinion that XYZ is not fully replaced by infinite gamut linear RGB if only because XYZ has a channel which is a proper luminance channel. RGB does not.
Enough to deserve a place within GIMP? Don't know. If my (initial) inputs and (final) outputs are sRGB, linear RGB with sRGB primaries is a better all around choice. But not a full replacement when you use nonlinear filtering.
Enough to deserve a place in babl/GEGL, but I think the ways they are going to be used (by image processing algorithms) is well enough covered without explicitly storing / confronting the user with an XYZ image mode.
/
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
lcms high bit depth update: now that it works, adding and improving functionality
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?
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?
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.
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.
Elle
Elle Stone http://ninedegreesbelow.com - articles on open source digital photography
lcms high bit depth update: now that it works, adding and improving functionality
On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone 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.
/ --
lcms high bit depth update: now that it works, adding and improving functionality
On 11/29/12, yvind Kols wrote:
On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone 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.
Even if babl could handle many of the more commonly used ICC profiles, Gimp/gegl would still need to be able to handle ICC profile conversions, because no matter how many specific ICC profiles babl is modified to handle, there will still be ICC profiles that babl can't handle. Consider custom or odd/unusual RGB working space profiles, the plethora of CMYK profiles, and custom input (eg camera, scanner), monitor, and output (eg printer) profiles. So it seems like creating custom babl formats for specific ICC profiles would mean a lot of extra code for babl, and Gimp/gegl would also need additional code to check to see whether the requested ICC profile conversion was already programmed into babl or not.
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.
I looked at http://gegl.org/babl/#Vocabulary but didn't understand it. However, adding in support for 16-bit floating point turned out to be straightfoward:
else if (type == babl_type ("half"))
{
if (has_alpha)
{
lcms_format = TYPE_RGBA_HALF_FLT;
iter_format = babl_format ("R'G'B'A half");
}
else
{
lcms_format = TYPE_RGB_HALF_FLT;
iter_format = babl_format ("R'G'B' half");
}
}
How/where do I submit a patch? Should I open an "lcms plugin enhancement" bug report? Does Mitch want sequential small patches that make one change at a time? Or does he want a bunch of changes all at once?
I also coded in the ability to assign an ICC profile to a grayscale image, and to convert grayscale images from one ICC profile to another. Unfortunately the display-filter-lcms.c module disables color management for the display of anything other than RGB images. However, upon exporting the Gimp-converted grayscale image, krita opens and displays the exported image correctly, and the image numbers look right, so the actual lcms.c grayscale profile conversion code works.
I suppose what Gimp/gegl really wants is grayscale to RGB, CMYK to RGB, etc, and then the other way upon exporting an image. Can gegl handle grayscale images or n-channel images where "n" is greater than 3? Or does it always require 3 channels of information?
Although Gimp can convert an image from whatever starting precision to 16-bit floating point, there doesn't seem to be any way to export the resulting image as 16-bit floating point or to import 16-bit floating point images.
Is the Gimp/babl 16-bit floating point the same as OpenExr 16-bit floating point? Is there a Gimp OpenExr plugin? Cinepaint outputs 16-bit floating point OpenExr tiffs, which Gimp opens as a 16-bit *integer* image. The image requires an extreme white point/black point adjustment and also a gamma correction to make it look like the original image.
The fits format supports 32- and 64-bit integer and floating point; OpenExr supports 32-bit integer and 32-bit floating point as well as 16-bit floating point. What bit-depth/precision does gegl use?
The lcms plugin code for 32-bit integer images would be just as simple as the 16-bit floating point code, except it will probably require writing a custom lcms_format. The lcms documentation on this procedure is a bit too sparse for me to understand, so I'll have to ask on the lcms mailing list.
Elle
http://ninedegreesbelow.com - articles on open source digital photography
lcms high bit depth update: now that it works, adding and improving functionality
On Sat, Jan 12, 2013 at 4:43 PM, Elle Stone wrote:
Is the Gimp/babl 16-bit floating point the same as OpenExr 16-bit floating point? Is there a Gimp OpenExr plugin?
There's a plug-in that uses GEGL loaders and savers fir multiple file formats.
http://git.gnome.org/browse/gimp/tree/plug-ins/common/file-gegl.c
It probably doesn't support multilayer EXR files which are fairly common in CG and architectural visualization. Which would be a pity.
Alexandre Prokoudine http://libregraphicsworld.org
lcms high bit depth update: now that it works, adding and improving functionality
On Sat, Jan 12, 2013 at 4:43 PM, Elle Stone wrote:
The fits format supports 32- and 64-bit integer and floating point;
As Mitch said, the newly ported FITS loader is a straightforward port of the legacy plug-in, it only deals with 8bit data, not 16, 32 and 64bit integers or floats. Someone would have to fix that.
Alexandre Prokoudine http://libregraphicsworld.org
lcms high bit depth update: now that it works, adding and improving functionality
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.
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.
You can either place your patches on the bugtracker like you said, or you can jump on irc and ask someone to apply them for you. You probably want to separate your work out into one patch for each change you make. (Although, feel free to lump a few small changes together if they're related - it is possible to go overboard with the "separate into tiny patches" mentality.)
-- drawoc
On Sat, Jan 12, 2013 at 7:43 AM, Elle Stone wrote:
On 11/29/12, yvind Kols wrote:
On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone 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.
Even if babl could handle many of the more commonly used ICC profiles, Gimp/gegl would still need to be able to handle ICC profile conversions, because no matter how many specific ICC profiles babl is modified to handle, there will still be ICC profiles that babl can't handle. Consider custom or odd/unusual RGB working space profiles, the plethora of CMYK profiles, and custom input (eg camera, scanner), monitor, and output (eg printer) profiles. So it seems like creating custom babl formats for specific ICC profiles would mean a lot of extra code for babl, and Gimp/gegl would also need additional code to check to see whether the requested ICC profile conversion was already programmed into babl or not.
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.
I looked at http://gegl.org/babl/#Vocabulary but didn't understand it. However, adding in support for 16-bit floating point turned out to be straightfoward:
else if (type == babl_type ("half")) {
if (has_alpha)
{
lcms_format = TYPE_RGBA_HALF_FLT; iter_format = babl_format ("R'G'B'A half"); }
else
{
lcms_format = TYPE_RGB_HALF_FLT; iter_format = babl_format ("R'G'B' half"); }
}How/where do I submit a patch? Should I open an "lcms plugin enhancement" bug report? Does Mitch want sequential small patches that make one change at a time? Or does he want a bunch of changes all at once?
I also coded in the ability to assign an ICC profile to a grayscale image, and to convert grayscale images from one ICC profile to another. Unfortunately the display-filter-lcms.c module disables color management for the display of anything other than RGB images. However, upon exporting the Gimp-converted grayscale image, krita opens and displays the exported image correctly, and the image numbers look right, so the actual lcms.c grayscale profile conversion code works.
I suppose what Gimp/gegl really wants is grayscale to RGB, CMYK to RGB, etc, and then the other way upon exporting an image. Can gegl handle grayscale images or n-channel images where "n" is greater than 3? Or does it always require 3 channels of information?
Although Gimp can convert an image from whatever starting precision to 16-bit floating point, there doesn't seem to be any way to export the resulting image as 16-bit floating point or to import 16-bit floating point images.
Is the Gimp/babl 16-bit floating point the same as OpenExr 16-bit floating point? Is there a Gimp OpenExr plugin? Cinepaint outputs 16-bit floating point OpenExr tiffs, which Gimp opens as a 16-bit *integer* image. The image requires an extreme white point/black point adjustment and also a gamma correction to make it look like the original image.
The fits format supports 32- and 64-bit integer and floating point; OpenExr supports 32-bit integer and 32-bit floating point as well as 16-bit floating point. What bit-depth/precision does gegl use?
The lcms plugin code for 32-bit integer images would be just as simple as the 16-bit floating point code, except it will probably require writing a custom lcms_format. The lcms documentation on this procedure is a bit too sparse for me to understand, so I'll have to ask on the lcms mailing list.
Elle
-- http://ninedegreesbelow.com - articles on open source digital photography
lcms high bit depth update: now that it works, adding and improving functionality
Michael Henning wrote:
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.
Take a look at the ICC file format. It is not something simple like a palette, it has about 34 different tag types, many of which are non-trivial to parse, represent and use. (The ICC also has a number of addition tag types such as floating point and spectral data tags waiting in the wings.) Why would you want to write (and maintain in the face of ICC format changes) duplicates of all the proven and tested logic that already exists in libraries like lcms, icclib etc. to parse and interpret ICC profiles ?
If you want to tag a colorspace when it is defined by an ICC profile, then the simplest thing to do is to tag it with the ICC profile. Store (or reference) the profile. Use all the existing ICC format code out there. Don't start on a mountain of a project to turn an ICC profile into some other format, unless you have an absolutely compelling reason, and lots of time on your hands...
Graeme Gill.
lcms high bit depth update: now that it works, adding and improving functionality
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.
babl should not require lcms, so it would be conditionally compiled when lcms is present.
-- drawoc
On Sun, Jan 13, 2013 at 7:27 PM, Graeme Gill wrote:
Michael Henning wrote:
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.Take a look at the ICC file format. It is not something simple like a palette, it has about 34 different tag types, many of which are non-trivial to parse, represent and use. (The ICC also has a number of addition tag types such as floating point and spectral data tags waiting in the wings.) Why would you want to write (and maintain in the face of ICC format changes) duplicates of all the proven and tested logic that already exists in libraries like lcms, icclib etc. to parse and interpret ICC profiles ?
If you want to tag a colorspace when it is defined by an ICC profile, then the simplest thing to do is to tag it with the ICC profile. Store (or reference) the profile. Use all the existing ICC format code out there. Don't start on a mountain of a project to turn an ICC profile into some other format, unless you have an absolutely compelling reason, and lots of time on your hands...
Graeme Gill.
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
lcms high bit depth update: now that it works, adding and improving functionality
On 1/13/13, Michael Henning 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 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
lcms high bit depth update: now that it works, adding and improving functionality
On Tue, 2013-01-15 at 11:25 -0500, Elle Stone wrote:
On 1/13/13, Michael Henning 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.
Just to clarify, that's exactly what he meant, and the formats would be created dynamically, as GIMP needs them.
No time to respond to the rest right now :)
regards, --mitch
