Maintaining buffers in a custom format in GIMP for EXR support
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.
| Maintaining buffers in a custom format in GIMP for EXR support | Mukund Sivaraman | 26 Feb 09:55 |
| Maintaining buffers in a custom format in GIMP for EXR support | Alexandre Prokoudine | 26 Feb 10:05 |
| Maintaining buffers in a custom format in GIMP for EXR support | Mukund Sivaraman | 26 Feb 10:19 |
| Maintaining buffers in a custom format in GIMP for EXR support | Elle Stone | 26 Feb 14:34 |
Maintaining buffers in a custom format in GIMP for EXR support
Hi all
This is a description of a way for the file-exr plug-in to create a buffer in GIMP with the OpenEXR source data retained exactly. It could also be used by other file formats to retain exact source data in the gegl buffer. It seems like hack to me, so I'm sending it here for discussion.
A GIMP plug-in runs as a different process from the GIMP app. So any gegl/babl formats/conversions it creates is limited to that plug-in's address space. The GIMP app doesn't know about it.
The app needs to be aware of the format in which a buffer's data is passed from the plug-in to the app. It has to create a BablFormat for it inside the app. The plug-in knows about the format and it has to pass this to the app.
A libgimp function call to setup the formats in both the app's and plug-in's address spaces respectively is a consistent way to achieve this. The plug-in can pass chromaticities as args to this function. There has to be a way to associate these two formats in the app and in the plug-in respectively, and it could be the format's name. The format's name would have to be automatically generated so that it is unique for every set of chromaticities. A simple counter in the format's name would be sufficient make such unique names such as "GIMP format %u".
No processing code (except operations such as crop and external/file) would process data in these custom formats. No processing code would look up these formats by name, but they would request a buffer in the formats they are aware of, i.e., in the working space of the operation.
Because babl has no support for chromaticities, GIMP would need to provide extension code to babl, that can convert these custom formats to a working space by maintaining a map from the format's name to a struct chromaticities and registering additional conversions with every format, where the format name is passed as user data. Such extensions may last for the lifetime of the app process.
When babl gets support for creating formats with chromaticities as in the roadmap, this last step can be removed.
Does this sound reasonable?
Mukund
Maintaining buffers in a custom format in GIMP for EXR support
On Thu, Feb 26, 2015 at 12:55 PM, Mukund Sivaraman wrote:
Because babl has no support for chromaticities, GIMP would need to provide extension code to babl, that can convert these custom formats to a working space by maintaining a map from the format's name to a struct chromaticities and registering additional conversions with every format, where the format name is passed as user data. Such extensions may last for the lifetime of the app process.
A somewhat unrelated question... With proposed changes, would the plugin be able to handle loading, then exporting single-channel greyscale EXR files?
Alex
Maintaining buffers in a custom format in GIMP for EXR support
On Thu, Feb 26, 2015 at 02:05:44PM +0400, Alexandre Prokoudine wrote:
A somewhat unrelated question... With proposed changes, would the plugin be able to handle loading, then exporting single-channel greyscale EXR files?
It can, and it can also write single-channel with the original data as-is (though chromaticities aren't defined in this case in the EXR format). The file plug-in would have access to the original data as-is to do as it wants with it.
I wonder if the proposed method is necessary though. Maybe all this already happens behind the scenes when an icc is passed as a parasite. Would gimp_drawable_get_buffer() return a buffer in the appropriate format? I don't know what the plans are, so that's why I ask. :)
Mukund
Maintaining buffers in a custom format in GIMP for EXR support
On 02/26/2015 04:55 AM, Mukund Sivaraman wrote:
Because babl has no support for chromaticities, GIMP would need to provide extension code to babl, that can convert these custom formats to a working space by maintaining a map from the format's name to a struct chromaticities and registering additional conversions with every format, where the format name is passed as user data. Such extensions may last for the lifetime of the app process.
When babl gets support for creating formats with chromaticities as in the roadmap, this last step can be removed.
The proposed approach will work for linear gamma OpenEXR files that have embedded chromaticities, but only if the chromaticities are correct.
Here's a counter-proposal that cleanly separates importing RGB data from processing RGB data:
For now:
1. Forget about OpenEXR metadata; deal with this as time permits.
2. Change the plug-in to treat OpenEXR as "gamma" rather than "linear" and treat the file as an untagged image.
3. GIMP will assign the built-in sRGB profile, which almost certainly will be wrong. Or else GIMP could make and assign the linear gamma sRGB profile to OpenEXR images, which would be right for many OpenEXR images that the user might open.
4. Then if the "auto-assigned" profile is wrong, the user can assign the correct ICC profile, which for actual linear gamma sRGB images (tiff or OpenEXR or otherwise) will be the linear gamma sRGB profile.
5. Distribute a set of ICC profiles with GIMP. At least distribute the regular and linear gamma sRGB profiles matching GIMP's built-in primaries, because there are too many bad sRGB profiles floating around out there.
Now the image has been assigned the correct ICC profile. So the next problem is that the RGB data might not be in the regular sRGB color space. This is a problem for two reasons:
i. The babl flips assume the image RGB data is encoded using the sRGB TRC.
ii. A handful of editing operatons assume the image's color space has the sRGB Y or XYZ values. Also masks are currently drawn using the sRGB Y values.
There are several interim ways to deal with these two problems that fall short of writing full support for chromaticities into babl.
If the RGB data isn't already regular sRGB data, you can:
1. Write GIMP code that automatically makes a profile that has the sRGB TRC and the user's chosen XYZ values. Then convert the image to this newly-made profile.
2. Write code that allows the user to disable the babl flips and then leave the data in the user's chosen RGB working space.
The problem with the first two approaches is that the babl/GEGL/GIMP editing operations that assume the sRGB Y or XYZ values will give the wrong results.
As nobody expects 2.10 to provide perfect color management, either or both of the above options seem like really good options to me.
The next two approaches are more problematic:
3. Write GIMP code that automatically converts the image to bounded sRGB. There are two problems with this approach:
i. The user really might need to edit the RGB values in the original color space, because many editing operations (including multiply) are chromaticity-dependent.
ii. Image colors might be clipped.
4. As was mentioned recently on IRC (not by me!), for the 2.10 release write GIMP code that automatically converts the image to unbounded sRGB. The many reasons why the fourth option is not a good idea have already been covered at length on this mailing list, so I don't plan to rehearse them yet again (all you people over there cheering loudly, that's not nice! :) ).
Elle
