Re: [Gimp-developer] 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 dra...@darkrefraction.com 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 l.elle.st...@gmail.com wrote:
On 11/29/12, Øyvind Kolås pip...@gimp.org wrote:
On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone l.elle.st...@gmail.com 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
Re: [Gimp-developer] 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. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality
On 11/29/12, Øyvind Kolås pip...@gimp.org wrote:
On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone l.elle.st...@gmail.com 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
Re: [Gimp-developer] 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality
On Fri, Nov 30, 2012 at 7:28 AM, Elle Stone l.elle.st...@gmail.com 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@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 9:23 AM, Elle Stone l.elle.st...@gmail.com 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. /Ø ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 2:57 AM, Øyvind Kolås 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 10:18 AM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Nov 29, 2012 at 2:57 AM, Øyvind Kolås 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 :) /Ø ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] 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. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] lcms high bit depth update: now that it works, adding and improving functionality
On Thu, Nov 29, 2012 at 10:36 AM, Nicolas Robidoux nicolas.robid...@gmail.com 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
Re: [Gimp-developer] 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 Kolås pip...@gimp.org wrote: On Thu, Nov 29, 2012 at 10:36 AM, Nicolas Robidoux nicolas.robid...@gmail.com 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
