GNOME Bugzilla – Bug 316646
Support for the file format OpenEXR
Last modified: 2016-05-20 18:21:43 UTC
This is not a bug, it's a required feature. Some info can be found at http://www.openexr.com/
It probably doesn't make much sense to add OpenEXR support unless GIMP can handle the high color depths that this format has been designed for.
It is possible to add a openexr reader in gtk that only reads images, converts to pixbufs and displays them. This is the same as displaying with exrdispay at exposure 0. This way one could display openexr images in nautilus, eog, etc... 1. Add io-openexr.c to gdk-pixbuf (by copying jpeg.c or a simple one) 2. Reading an image amounts to the following: void readRgba1 (const char fileName[], Array2D<Rgba> &high_pixels, int &width, int &height) { RgbaInputFile file (fileName); Box2i dw = file.dataWindow(); width = dw.max.x - dw.min.x + 1; height = dw.max.y - dw.min.y + 1; pixels.resizeErase (height, width); file.setFrameBuffer (&pixels[0][0] - dw.min.x - dw.min.y * width, 1, width); file.readPixels (dw.min.y, dw.max.y); 3. Convert Openexr pixels to low depth: int* low; for all pixels: low_pixels[].red = 255 * high_pixels.r ( and shift accordingly)
(In reply to comment #2) > It is possible to add a openexr reader in gtk that only reads > images, converts to pixbufs and displays them. This is unlikely to happen in gtk+, because OpenEXR is a rather specialized file format and very few applications could make good use of it. If support for OpenEXR is added, then it should be in GIMP or in other applications dealing with image manipulations or viewing. But as Sven mentioned in comment #1, supporting OpenEXR in GIMP should probably be done after GIMP supports more than 8 bits per color channel. Although if you have time, feel free to implement a plug-in that supports OpenEXR and reduces the color depth of the images. Then submit it to http://registry.gimp.org/.
This bug depends on the GEGL infrastructure that will be used to fix bug 74224.
EXR support is now in master, though I wouldn't call it complete yet.
I've been importing and exporting exr files to and from Gimp for a while now. My oldest copy of babl/gegl/Gimp from git (at least a month old, probably two months old) imports and exports exr files just fine. However, babl/gegl/Gimp from git from a couple of days ago can import exr files but can't export them. The file type option is gone from the dropdown list. What happened? With exr support, and with darktable already capable of exporting a 32-bit floating point exr file, and with RT working in that direction (if not already there), an image can go from rendered raw file to xcf and back to disk for processing elsewhere without ever dropping to 16-bits.
GIMP got its own EXR plug-in, and it's still incomplete, it will improve.
Created attachment 289840 [details] [review] Restore ability to open and save an OpenEXR file
Mitch, any reason why this patch is not validated? It still applies against the tree and seems to work ok (I could save in exr once I applied it, though I could not before, I did not test much more).
Because simply it disables the new GIMP plug-in and uses the GEGL op instead, if something is wrong with the newly added plug-in that should be fixed. The part of the patch that changes the OpenEXR plug-in, is that correct? Are the images all gamma corrected?
Jehan: I've added just the save path through file-gegl such that loading still happens with the native plug-in. Check if it works for you now. Elle: Can you point into the OpenEXR reference documentation re the gamma change? (I'm not able to find a reference for it)
Created attachment 297093 [details] Colors are wrong with Elle's patch. Mukund: loading an exr was already working, even before Elle's patch or your recent commit. Exporting in EXR on the other hand was not working. It does since your commit. So that's good. Mukund and Mitch: As for Elle's proposed change on gama corrected color, I *think* it's wrong. Now I've not checked the format specification or anything, so I may be wrong; but simply in my basic tests, the colors of the imported image were wrong with Elle's patch. My test image was a direct export from Blender in EXR of the default 3D scene (the grey cube). This grey cube appeared black/dark grey when I imported it in GIMP with Elle's patch. See the attached screenshot comparing the EXR file's preview and the result in GIMP. So unless Blender's implementation is wrong too, the proposed gama correction is wrong. On the other hand, current master code seems fine. Color appears grey as in Blender or in the preview. So I think it's all good. Should we close the report or is there any other things to fix?
For reference: commit 09f64866c2ab091775f52dcc2ac2732761c6bc29 Author: Mukund Sivaraman <muks@banu.com> Date: Wed Feb 18 13:40:14 2015 +0530 file-gegl: Add OpenEXR saving through file-gegl
Please don't close this bug yet. The colors are correct ONLY if the user opens an exr file that is: *linearly encoded, which is not a requirement for the openexr file format. *encoded using the sRGB primaries, which is also not a requirement for the openexr file format. The colors are also only correct if the user hasn't chosen in GIMP preferences an RGB working space other than the built-in GIMP sRGB working space. For example, try changing your chosen RGB working space to a linear gamma ProPhotoRGB ICC profile and reopening your blender exr file.
Hi Elle (In reply to Elle Stone from comment #14) > *linearly encoded, which is not a requirement for the openexr file format. I asked you for a reference for this item, so that we can settle on what's right instead of taking somebody's word for it. Your patch changed the behaviour to assume that stored values were gamma corrected. The following are some references on the openexr.com website on this: 1. http://www.openexr.com/TechnicalIntroduction.pdf "By convention, OpenEXR stores scene-referred linear values in the RGB floating-point numbers." 2. http://www.openexr.com/photoshop_plugin.html "Most images, such as JPEGs or TIFFs, are stored with an implicit gamma encoding of 2.2, the standard for video images. OpenEXR images are stored with no gamma correction."
Hi Elle, Additionally to the reference that Mukund is asking you, would you have an OpenEXR example file not linearly encoded, and an other one not using sRGB primaries? It does not look like Blender is capable to render such files (could not find the option at least) and I don't know which other software could export such files. This would help for devs to test. Thanks.
Hi Jehan and Mukund, It will take a couple of hours for me to comply with your requests (other things to also deal with).
Hi Elle (In reply to Elle Stone from comment #17) > Hi Jehan and Mukund, > > It will take a couple of hours for me to comply with your requests (other > things to also deal with). Take your time. This bug has been open for several years now, after all. :) File formats are nasty business and there are all sorts of files one comes across written by broken software. We try to be correct to a spec if one exists for that format. That's why I'm keen on seeing a reference so this doesn't get more bug reports in the future.
Thanks for checking everybody. And Elle, sorry I miserad your patch and thought it would disable the GIMP plug-in, when in fact it simply adds loading. Closing as fixed by this commit: commit 09f64866c2ab091775f52dcc2ac2732761c6bc29 Author: Mukund Sivaraman <muks@banu.com> Date: Wed Feb 18 13:40:14 2015 +0530 file-gegl: Add OpenEXR saving through file-gegl
Mitch, Elle is telling us in comment 14 that there would be cases where the color would be broken on import. So we asked her for spec references and example images. So we reopen until she returns the references.
Oh, indeed, sorry.
Created attachment 297122 [details] apples-regularsrgb.exr
Created attachment 297123 [details] apples-linear-srgb.exr
Created attachment 297124 [details] apples-linear-prophoto.exr
Created attachment 297125 [details] apples-prophoto18.exr
Created attachment 297126 [details] apples-clayg22.exr
Regarding "Your patch changed the behaviour to assume that stored values were gamma corrected" my patch did change the file opening behavior so that babl/GEGL/GIMP doesn't apply the sRGB TRC to the OpenEXR data upon opening the file. The only way I know of to do this is to tell GIMP that the image is already "gamma corrected". At some point it was decided that some file formats are always "gamma corrected", presumably to the sRGB TRC, and some file formats are always "linear" and so upon opening should be corrected to the sRGB TRC. Contrary to this coding assumption, tiffs and pngs can be encoded using any TRC, including the linear gamma TRC, and 32-bit data is not necessarily linear. OpenEXR is a file format for storing high precision data. Usually that data is encoded linearly, simply because the people who use OpenEXR usually want to manipulate linearized data. So for example page 1 of <http://www.openexr.com/OpenEXRColorManagement.pdf> says "OpenEXR images are usually scene-referred: The floating-point red, green and blue values in an image are proportional to the relative amount of light coming from the corresponding objects in the depicted scene." Notice the word "usually". There is no requirement that OpenEXR data be encoded linearly. It can be encoded using any TRC (tone reproduction curve) the user desires, be it the sRGB TRC, gamma=1.0, gamma=1.8, gamma=2.2, BT.709, lstar. Nothing in the OpenEXR code that opens or writes OpenEXR data verifies, rejects, accepts, or otherwise cares one way or the other about whether the RGB data is linearized or not. I know this to be true not because I've read through the OpenEXR code, but because I use OpenEXR data in my normal workflow to transport 32-bit floating point data between editing applications, specifically between GIMP, Krita, and darktable. When reading and writing OpenEXR files, OpenEXR doesn't throw an error if the RGB data is encoded nonlinearly. All it does is read and write RGB values (it can read and write other data such as XYZ and xyY, but I'm only talking about RGB data). As currently programmed, default GIMP: * assumes that OpenEXR data is linear. * applies the sRGB TRC "gamma correction" to it. * assigns either the GIMP built-in sRGB profile (if the user hasn't chosen an RGB working space in the color management preferences), or else whatever ICC profile the user has chosen as the RGB working space. Attached are 5 small OpenEXR files, in five different RGB working spaces with various combinations of primaries and TRCs: * In a copy of GIMP patched using my patch to allow opening and exporting OpenEXR images, upon opening all five files, to get the correct colors all I have to do is tell GIMP which ICC profile to apply. * In a copy of default GIMP (with or without the latest patch to write OpenEXR files), the only attached file that opens correctly is the linear gamma sRGB OpenEXR file, assuming, of course, that the user hasn't chosen in the Color Management Preferances an RGB working space other than the GIMP built-in sRGB profile or an equivalent profile from disk. Unfortunately, in babl/GEGL/GIMP as currently programmed, the "babl flips" TRC for all images is assumed to be the sRGB TRC. Which brings us back around to the problem of creating an ICC profile with the sRGB TRC and the user's chosen RGB working space primaries, and also the problem of coding in a way for the user to choose the TRC used in the babl flips.
Upon reflection, a partial retraction: On the one hand, the OpenEXR file format can store nonlinearly encoded RGB data. All the user needs is the right ICC profile to apply to the image, but the image shouldn't have had the sRGB TRC applied to it, as currently happens with GIMP. On the other hand, applications that use OpenEXR images for compositing HDR data do need linearly encoded RGB data. Only recently did I realize that one even could save nonlinearly encoded RGB data using OpenEXR, as per this post: https://mail.gnome.org/archives/gimp-developer-list/2013-November/msg00050.html The OpenEXR people seem not at all interested in extending OpenEXR to explicitly provide support for ICC profiles and perhaps by extension they aren't interested in supporting a photographic workflow: https://lists.nongnu.org/archive/html/openexr-devel/2005-11/msg00017.html https://lists.nongnu.org/archive/html/openexr-devel/2012-11/msg00002.html It might be reasonable for GIMP to expect that OpenEXR files are linear, although it would also be an unnecessary restriction on the data that can be transported back and forth between editing applications. Either way, the user needs to be able to assign the correct ICC profile to the data. It won't always be sRGB data. It would provide for a great deal more flexibility if the user could assign the right ICC profile and then convert to whatever working space the user wants to use. Right now that working space requires the sRGB TRC or else the babl flips give the wrong results: http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html#hard-coded-sRGB-TRC
To put this into a user-oriented context, only a handful of free/libre color-managed image editors allow importing, working with, and exporting 32-bit floating point images: Krita, GIMP 2.9, and darktable, plus Cinepaint for those users who can actually get Cinepaint to install on a recent Linux distribution. Any others? Different image editors have different strengths and weaknesses, and surely GIMP 2.9 users will want the ability to export an image from GIMP at 32-bit floating point precision so they can work on the image in other image editors. GIMP and darktable already can read each other's 32-bit floating point tiffs and OpenEXR images. Except darktable can write OpenEXR images that aren't linearly encoded and don't have the sRGB primaries. There is nothing in the OpenEXR file format specs that prohibits this from being done. If you like, I'll ask on some appropriate forum, but I'm sure about this. So if you want to enforce "only linear RGB data in an OpenEXR file", you are going to get complaints from users who try to do otherwise. GIMP as currently programmed can only properly import linearly encoded OpenEXR files with the sRGB primaries, and even then only if the user hasn't chosen a non-sRGB working space in the color management preferences. If the darktable user exports a linearly encoded ProPhotoRGB OpenEXR image, to open this image in GIMP the user will need to have available a profile with the ProPhotoRGB primaries and the sRGB TRC, to assign to the darktable-exported linear gamma ProPhotoRGB image to which GIMP has applied the sRGB TRC. There is something exceedingly odd about having to assign a profile with the sRGB TRC to an image that was exported by darktable as linearly encoded. This will not be easy to explain to users. If the darktable user exports a nonlinearly encoded ProPhotoRGB OpenEXR image, the user will not be able to open said OpenEXR file using GIMP. Because GIMP assumes tiffs are gamma-encoded, even when they really are encoded linearly, darktable and GIMP can easily exchange 32-bit floating point tiffs. Except before editing the image with GIMP the user will need to convert the image to a profile with the ProPhotoRGB primaries and the sRGB TRC, or the babl flips won't work properly.
OpenEXR Documentation regarding whether RGB values "must" be encoded linearly: ** OpenEXRFileLayout.pdf ************ **ReadingAndWritingImageFiles.pdf ************ These two PDFs say nothing about whether the RGB values must be encoded linearly or not. As a file format, OpenEXR has absolutely no way to detect what encoding was used to generated RGB values. It's just a file format. It's up to the user to know how the RGB values should be interpreted. ** TechnicalIntroduction.pdf ************ 1. If you store color data as Luminance/Chroma, you won't get the right results unless you are starting with linear data. As GIMP doesn't use this OpenEXR capability, it doesn't really matter. If GIMP adds support for this capability, it should be left up to the user to make sure the data so stored is linear data. GIMP shouldn't take on the role of making color management decisions for users. 2. "By convention, OpenEXR stores scene-referred linear values in the RGB floating-point numbers." "By convention" doesn't mean "is required". It just means that most people in the movie industry who use OpenEXR are usually using RGB data for purposes that require linearized (and specifically scene-linear) RGB data to work correctly. If your purpose doesn't require linearized RGB data, then you aren't required to linearize it before storing it as OpenEXR data. ** OpenEXRColorManagement.pdf ************ 1. "OpenEXR images are usually scene-referred: The floating-point red, green and blue values in an image are proportional to the relative amount of light coming from the corresponding objects in the depicted scene." The documentation says "usually". This is not a requirement for reading or writing OpenEXR files. 2. "The following proposes a color management scheme for OpenEXR images, which can be summarized as follows: • RGB data in OpenEXR files are always scene-referred. • Converting an image from another medium to OpenEXR RGB requires reconstruction of scene luminance values. • Viewing an image requires applying a transformation to the pixel data that produces the image's intended look." Above is a PROPOSED scheme for color managing OpenEXR images. It's not a requirement. This proposed scheme presupposes that other software is applying transformations to linearized pixel data to make it look like the artist wants it to look. GIMP is not set up to store unmodified OpenEXR data while applying SROM/OMRD/RDPD/CTL/etc transforms *outside* of the OpenEXR RGB data, all the while showing the user what the transformed data will look like when the transforms are eventually applied to the data. Once an OpenEXR file has been imported into GIMP, it's not even OpenEXR data any more. So any proposed scheme for color-managing OpenEXR data in a dedicated OpenEXR workflow is entirely irrelevant to what GIMP does with OpenEXR data. 3. Darktable is a likely source of OpenEXR files that users will want to import into GIMP. If a user processes a raw file using darktable it is highly likely that they will output an image that has been processed in ways that destroyed the scene-linear nature of the raw data that was captured by the camera sensor. Once the scene-linear data has already been destroyed, encoding the RGB data linearly doesn't magically restore the original scene-linear data. In a photographic workflow, requiring that OpenEXR data be encoded linearly is an arbitrary restriction on what the artist can do with her own RGB data. In a photographic image editing application, whether or not the RGB data "should be" encoded linearly depends on what the artist wants to do with the data. GIMP is not set up in any way, shape, or form to use the proposed OpenEXR color management scheme. And again, it's a color management *proposal*, not a requirement for reading and writing OpenEXR files. ** UsingOpenEXRandCTL.pdf ************ This PDF outlines a proposed ACES workflow using OpenEXR to store image data. The GIMP devs want to know whether OpenEXR can be used to store nonlinearly encoded data. The answer is of course it can and this PDF specifically talks about storing output data that's not scene-linear, as part of an overall ACES workflow. See page 11, ImageState, which has three values: SCENE_LINEAR, INDIREDT_OUTPUT_REFERRED, and OUTPUT_REFERRED. The proposed ACES workflow is absolutely irrelevant to GIMP. The real question is how should GIMP handle OpenEXR images, to accomodate the needs of highly diverse GIMP users. The only workable answer is: * Don't assume the OpenEXR data is linear. * Don't assume it's encoded using the sRGB chromaticities. * Don't assume anything. * Let the user assign the correct ICC profile upon importing the OpenEXR file. * Don't "undo" the sRGB TRC before exporting the OpenEXR image. The user might have already converted the image to a linear gamma ICC profile. Or they might really want to export nonlinearly encoded RGB data. I have put a lot of time into reading and explaining OpenEXR documentation as it applies to GIMP. As requested, I've put together sample files showing you the kinds of problems you can expect to face down the line with the current code. It would be nice to see some indication that someone has actually paid any attention. Elle
Hi Elle Thank you for following up, and taking time to research it. I've read what you typed above. I agree on one point and disagree on another. Because I asked for it and you've taken time to research and type all this, I leave a reply for this bug. Someone else will continue with it if necessary. "Convention" here means the general way of things. OpenEXR has no field in the file to indicate whether values are linear or gamma corrected. They go so far as allowing you to specify RGB chromaticities; don't you think such a field would have been present too if gamma corrected values were to be supported? Just so this point about assumptions is abundantly clear: it is also stated as an assumption of the IlmImf library (an implementation of OpenEXR) that the channel named "R" stands for red, "G" for green, etc. The file format doesn't specify their meanings except reserving these names. OpenEXR is a processing format. Even when it is displayed, it is expected that a user will adjust the image, more so because it is in the OpenEXR format. If a user loads an EXR in a viewer and wants to view it 1 stop brighter using a slider, what would be the best source format for it? After reading your comments about Darktable exporting gamma corrected EXRs, I passed this along to houz (a Darktable developer) who agrees that exporting files with gamma corrected values ought not to happen. In the ACES workflow that you mention, you also mention that a field has been introduced for it to make the distinction clear. I agree that GIMP should not make assumptions about the chromaticities that it currently does now and use the corresponding field from the OpenEXR file if available, and this needs more work. What we can do in the meantime is to refuse to load EXRs that we cannot handle correctly. A lot of things are possible with different file formats. Just because they are possible, it doesn't mean we can support every one of the myriad variations or even that it is sensible to do so.
Created attachment 297491 [details] Problem with the current OpenEXR behavior
"What we can do in the meantime is to refuse to load EXRs that we cannot handle correctly." How do you know when you are loading an EXR that you can't open correctly? I used darktable to export a linear gamma OpenEXR image. The top row of the attached image "wrong-colors-for-image-exported-from-darktable-as-linear-gamma-exr.jpg" shows what the image looked like in darktable. I opened the image with default GIMP. GIMP did the "gamma correction" and assigned the built-in sRGB profile. The middle row of the attached image shows what the image looked like. The colors are wrong. Then I assigned the correct linear gamma ICC profile, that is, the profile that correctly interprets the RGB data that was actually exported by darktable. The bottom row of the attached image shows waht the image looked like. The colors are even more wrong. In a copy of GIMP patched using my original patch, I get the right colors by assigning the exact same linear gamma profile that I assigned as the output profile in darktable. For images as exported by Blender, to get the correct colors using my patch, assign a linear gamma sRGB profile. However much you might want to follow the OpenEXR specs as you interpret them, performing a gamma correction on linear gamma data and then arbitrarily assigning the regular sRGB profile will inevitably lead to situations where the user can't recover the correct values.
http://lists.nongnu.org/archive/html/openexr-devel/2015-02/msg00010.html Above is link to where I asked about nonlinear OpenEXR files. I think you all might have thought I was asking the actual OpenEXR devs. I don't even know if they have a mailing list. The openexr-devel list is for people who are developing applications that use OpenEXR.
Created attachment 297503 [details] [review] Add support for non-linear channels in OpenEXR Hi, In the file http://www.openexr.com/openexrfilelayout.pdf the header attribute "channels" (page 8) is of type "chlist" and page 14 details the layout of a chlist (a list of channel). In particular, I see that a channel has an attribute: > pLinear unsigned char, possible values are 0 and 1 In IlmImf code, file IlmImf/ImfChannelList.h, this flag is described as such: > //-------------------------------------------------------------- > // Hint to lossy compression methods that indicates whether > // human perception of the quantity represented by this channel > // is closer to linear or closer to logarithmic. Compression > // methods may optimize image quality by adjusting pixel data > // quantization acording to this hint. > // For example, perception of red, green, blue and luminance is > // approximately logarithmic; the difference between 0.1 and 0.2 > // is perceived to be roughly the same as the difference between > // 1.0 and 2.0. Perception of chroma coordinates tends to be > // closer to linear than logarithmic; the difference between 0.1 > // and 0.2 is perceived to be roughly the same as the difference > // between 1.0 and 1.1. > //-------------------------------------------------------------- > > bool@@@@@@@@@@@@@@@@pLinear; Well isn't it what we are looking for? It seems as if the chlist type ("channel" header attribute) would indicate for each channel whether it has been gamma-corrected or not (this is apparently a per-channel feature). In any case, I made a patch for this. See attached. If I misunderstood something in this spec, don't hesitate to tell.
WRT pLinear: http://lists.nongnu.org/archive/html/openexr-devel/2015-02/msg00030.html If you read through the entire thread, consider the context of the various replies. Most people using OpenEXR are working in an HDR scene-referred workflow where alterations to the RGB data are NOT WRITTEN to the OpenEXR file but rather stored and applied by various other modules in the workflow. This context doesn't yet and might not ever apply to GIMP. At present for GIMP OpenEXR is merely a convenient file format for transporting data between editing applications: * A Blender user might want to export a linear gamma sRGB image that might also be scene-linear, and open it with GIMP. * A darktable user might want to export a ProPhotoRGB image that has been modifed to be very far from scene-linear, and open it with GIMP. You can add metadata that indicates something about the state of the RGB data. But you can't assume that other editing applications can read that metadata. From an ICC profile color management point of view, OpenEXR is an untagged file format. So you assume sRGB. AND you give the user a chance to correct the assumption. Writing code that only works with linear gamma sRGB OpenEXR files is an arbitrary restriction that doesn't serve the needs of actual GIMP users. For a nice discussion of OpenEXR mixed with ICC profile color management, including a suggestion for how to embed ICC profiles in the OpenEXR metadata, see this thread (that isn't in the main thread because it was sent as part of a digest): http://lists.nongnu.org/archive/html/openexr-devel/2015-02/msg00031.html See this thread for context of the above reply: http://lists.nongnu.org/archive/html/openexr-devel/2015-02/msg00024.html
> If you read through the entire thread, consider the context of the various > replies. Most people using OpenEXR are working in an HDR scene-referred > workflow where alterations to the RGB data are NOT WRITTEN to the OpenEXR > file but rather stored and applied by various other modules in the workflow. Though the thread wandered off into things like viewing pipelines, there are plenty of situations where changes to RGB is written into new OpenEXR files and interchanged between various tools (or people). And in basically all of these situations, the RGB in the OpenEXR files is going to be "linear". > From an ICC profile color management point of view, OpenEXR is an untagged > file format. So you assume sRGB. By assuming sRGB - do you mean assuming both sRGB chromaticies and TRC, or just chromaticies (and assume the encoding is linear)?
(In reply to Karl Rasche from comment #37) > Though the thread wandered off into things like viewing pipelines, there are > plenty of situations where changes to RGB is written into new OpenEXR files > and interchanged between various tools (or people). Of course people write changes to OpenEXR files. > And in basically all of these situations, the RGB in the OpenEXR files is > going to be "linear". Maybe in your workflow this is true. But it's not true for everyone's workflow, all the time, under all circumstances. Regardless of how you decide to interpret the OpenEXR specs, nothing in the actual file format *prevents* users from writing nonlinear RGB data: http://lists.nongnu.org/archive/html/openexr-devel/2015-02/msg00042.html "My rationale is simple: I can't prevent users from putting non-linear pixels into an EXR file. The color information I get from these programs is an ICC profile, so that's the metadata I store. (I also do my best to convert the ICC info to EXR standard attributes like chroaticity.)" http://lists.nongnu.org/archive/html/openexr-devel/2013-07/msg00032.html "But I'll freely admit that I allow users to write EXR files off-spec. Not that I really have any control over it - I get pixels from After Effects and I write those pixels. If a user wants to store Rec709 data in an EXR, I'm not going to stop them. I know of at least one major studio that does this." If GIMP only allows reading and writing linear gamma OpenEXR data, and the aforementioned major studio wanted to send a file to a GIMP user, the GIMP user would have to say, "Sorry, I can't open the file." The real world of exchanging RGB data is messy. People write nonlinear OpenEXR files. GIMP should be able to open these files and also write them if that's what the user wants to do.
(In reply to Karl Rasche from comment #37) > > From an ICC profile color management point of view, OpenEXR is an untagged > > file format. So you assume sRGB. > > By assuming sRGB - do you mean assuming both sRGB chromaticies and TRC, or > just chromaticies (and assume the encoding is linear)? All properly written ICC profile color managed editing programs allow the user to assign a different ICC profile if the one that's "auto-assigned" isn't the right ICC profile. So it really doesn't matter what profile is automatically assigned to an OpenEXR image, as long as the user can then assign the correct ICC profile. If most OpenEXR files opened in GIMP can be assumed to be linear gamma sRGB files exported from Blender, then assigning a linear gamma sRGB file to OpenEXR files that don't provide any other indication of the actual color space would make the most sense. But again, it really doesn't matter. The user must have the opportunity to assign a different ICC profile. The problem with "gamma correcting" presumed linear gamma RGB to have the sRGB TRC, as GIMP currently does, is that even if the OpenEXR file really was a linear gamma file, after that "gamma correction" has been applied, assigning the linear gamma ICC profile that described the data before GIMP opened it, doesn't restore the proper colors, because the very process of opening the file (as GIMP is currently coded) alters the pixels. Arbitrarily applying the sRGB TRC "gamma correction" to presumed linear gamma RGB data leaves the data in a state from which the user can't recover the original data.
Hi Elle (In reply to Elle Stone from comment #38) > The real world of exchanging RGB data is messy. People write nonlinear > OpenEXR files. GIMP should be able to open these files and also write them > if that's what the user wants to do. As there's no way to detect whether an OpenEXR file has gamma corrected values (I'm not so sure by the description of the pLinear field which Jehan mentions, though it is aptly named), the current GIMP plug-in doesn't stop you from reading gamma corrected files. But you'll get a different image to what you saved because it's not linear. The "more work" that I mentioned in an earlier comment are about changes to GIMP itself, so GIMP doesn't break what file-exr sends it. The "refuse to load EXRs" was to refuse to load EXRs which have the chromaticities specified (temporarily while GIMP is fixed). Hotfixing what GIMP thinks is a linear image to a gamma corrected one could be possible in GIMP UI. But what I don't like is loading all EXR images as gamma corrected ones. Am I right in understanding that you decided to do this because it's not possible later to set a TRC (and not apply it), or that somehow GIMP screws up what you get from file-exr?
(In reply to Elle Stone from comment #39) > The problem with "gamma correcting" presumed linear gamma RGB to have the > sRGB TRC, as GIMP currently does, is that even if the OpenEXR file really > was a linear gamma file, after that "gamma correction" has been applied, > assigning the linear gamma ICC profile that described the data before GIMP > opened it, doesn't restore the proper colors, because the very process of > opening the file (as GIMP is currently coded) alters the pixels. Nod I follow now. This would equally apply to all formats, so the fix should not be in the EXR loader but in GIMP itself. GIMP is changing a lot in the master branch (so much, I find it hard to keep track) and hasn't stabilized esp. in regards to color, so even a change that file-exr makes now could become incorrect in the near future. GIMP core has to stabilize and offer a stable API for plug-ins to send it data so the app doesn't mess it up later.
(In reply to Mukund Sivaraman from comment #40) > As there's no way to detect whether an OpenEXR file has gamma corrected > values (I'm not so sure by the description of the pLinear field which Jehan > mentions, though it is aptly named), the current GIMP plug-in doesn't stop > you from reading gamma corrected files. But you'll get a different image to > what you saved because it's not linear. > > The "more work" that I mentioned in an earlier comment are about changes to > GIMP itself, so GIMP doesn't break what file-exr sends it. The "refuse to > load EXRs" was to refuse to load EXRs which have the chromaticities > specified (temporarily while GIMP is fixed). Hmm, I agree that an effort should be made to examine whatever metadata exists in the OpenEXR file and then try to construct an ICC profile to assign to the file, and also try to save adequately descriptive color data on export. However, upon importing an OpenEXR image, GIMP has no way to know where the metadata came from and whether it still applies, as handling of OpenEXR metadata varies from image editor to image editor. So for example whatever chromaticities or "pLinear" or After-Effects-type ICC profile information there might be in the metadata, might have just been left over from three processing steps back. A similar problem obtains with camera-generated DCF color space information. You don't really know if the DCF information still applies. So you write code that makes a "best guess" based on the available metadata, and then give the user an opportunity to correct the "best guess" if that guess isn't right.
(In reply to Mukund Sivaraman from comment #41) > (In reply to Elle Stone from comment #39) > > The problem with "gamma correcting" presumed linear gamma RGB to have the > > sRGB TRC, as GIMP currently does, is that even if the OpenEXR file really > > was a linear gamma file, after that "gamma correction" has been applied, > > assigning the linear gamma ICC profile that described the data before GIMP > > opened it, doesn't restore the proper colors, because the very process of > > opening the file (as GIMP is currently coded) alters the pixels. > > Nod I follow now. This would equally apply to all formats, so the fix should > not be in the EXR loader but in GIMP itself. > > GIMP is changing a lot in the master branch (so much, I find it hard to keep > track) and hasn't stabilized esp. in regards to color, so even a change that > file-exr makes now could become incorrect in the near future. GIMP core has > to stabilize and offer a stable API for plug-ins to send it data so the app > doesn't mess it up later. It seems to me that the real source of the problem is the rather unwarranted implicit assumption that the file format somehow dictates the nature of the RGB data that's contained in the file format. I would suggest that *all* file formats be set to "gamma corrected" upon import and export. This avoids having the RGB data "gamma corrected" by applying the sRGB TRC. This sounds wrong if the file is really a linear gamma file. But until the correct ICC profile has been assigned to the image, there is no way for GIMP to know what kind of data is stored in the file. So for example, right now if a user exports a linear gamma ProPhoto 32f tiff from darktable, and also exports the same linear gamma RGB data as an OpenEXR file, upon opening the two files with GIMP, the RGB data is sent down two different processing paths upon opening, depending entirely upon the file format. With the tiff, GIMP will read and use the embedded ICC profile. With the OpenEXR file - same RGB data - upon opening the file with GIMP the data is given the sRGB TRC "gamma correction", and when the user assigns the linear gamma ProPhoto ICC profile, the colors are wrong. If the tiff had somehow been stripped of the ICC profile (it does happen), GIMP would assign the built-in sRGB profile and the user would have an opportunity to assign the correct ICC profile. This is not the case with OpenEXR data, simply because it's currently considered "linear" by virtue of the file format. I understand that the desire is to get the RGB data into the right "linear" or "gamma" processing pipeline, and that the current pipeline is only set up to handle the sRGB TRC for the "gamma" pipeline". But first you have to establish the nature of the RGB data, which really can't be determined by the file format.
> All properly written ICC profile color managed editing programs allow the > user to assign a different ICC profile if the one that's "auto-assigned" > isn't the right ICC profile. True - provided the user is able to divine the right profile to use. Its also true that nonlinear RGB in openexr files does happen, and that case needs to be handled somehow. However, the absence of a mechanism preventing you from writing nonlinear rgb is somewhat different from an endorsement that writing nonlinear rgb is a good idea. Nonlinear rgb in openexr is an edge case, and usually is a sign that something is wonky in the workflow. One advantage of preferring linear rgb is that when metadata is lost or forgotten, you don't need to question the encoding in the common case. Otherwise, you would need to guess the nonlinear encoding, of which there are plenty of choices. > The problem with "gamma correcting" presumed linear gamma RGB to have the > sRGB TRC, as GIMP currently does, is that even if the OpenEXR file really > was a linear gamma file, after that "gamma correction" has been applied, > assigning the linear gamma ICC profile that described the data before GIMP > opened it, doesn't restore the proper colors, because the very process of > opening the file (as GIMP is currently coded) alters the pixel Agreed. Karl
(In reply to Karl Rasche from comment #44) > Its also true that nonlinear RGB in openexr files does happen, and that case > needs to be handled somehow. However, the absence of a mechanism preventing > you from writing nonlinear rgb is somewhat different from an endorsement > that writing nonlinear rgb is a good idea. Absolutely agreed. > One advantage of preferring linear rgb is that when metadata is lost or > forgotten, you don't need to question the encoding in the common case. > Otherwise, you would need to guess the nonlinear encoding, of which there > are plenty of choices. Agreed. Guessing the right chromaticities is hard enough without also having to guess what nonlinear encoding might have been used.
Just for the record, a few days ago I added support for reading the color space information stored in EXR files when loading them. Since there is no documented standard way to determine a gamma value they are assumed to be linearly encoded with the set white/black point and chromaticities. Images without such information get loaded as linear REC709 (i.e., linear sRGB, bablRGB, or whatever you like to call it). Just applying a color profile seems to work fine for these images. This allows to load images from darktable that got exported with any linear profile and get consistent colors. Relevant commit: commit d73cfa4a24211f67889b84aeae8f70282ce33d3b Author: Tobias Ellinghaus <me@houz.org> AuthorDate: Sun Sep 20 23:42:24 2015 +0200 Commit: Tobias Ellinghaus <me@houz.org> CommitDate: Sun Sep 20 23:42:24 2015 +0200 plug-ins: support color managed EXR loading This generates an ICC profile from the embedded white point and chromaticities on the fly, assuming linear gamma images.
Is anybody having atrocious performance? Even on image of size 4x3 the zoom is very slow.
Too. Much. Information. Do we have some conclusion here? This bug is on the 2.10 milestone after all.
All the sample exr files attached to this bug report can be opened and assigned the right ICC profile from disk. Upon opening they are all assigned the linear precision and the built-in linear gamma sRGB profile. The only problematic file is apples-regularsrgb.exr. Assigning the built-in sRGB profile is not an option at linear precision (and all exr files open at linear precision). Changing to perceptual precision alters the pixel values. So what the user really needs to do if s/he is trying to open an exr file that holds regular sRGB data is assign a regular sRGB profile from disk, which does work. Also upon exporting an image from darktable as openexr and opening with GIMP, the embedded chromaticities seem to be interpreted correctly and match the result of opening the same file exported from darktable as a 32-bit floating point tif. So to me this bug looks fixed.
Thanks, so it seems. Also, there isn't much more we can do right now, so in the scope of this bug let's call it fixed :)
FWIW the OpenEXR project includes some test images at https://github.com/openexr/openexr-images
Thanks. Could you be so kind and try loading them all, reporting which ones fail? Preferably in a new bug report.