[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
Regardless of what darktable should do as an editor, it still effectively means that any compliant viewer will display a border around EXR files exported by Hugin. I find it extremely hard to believe that this border is there on purpose. “all place where images are loaded or saved would be checked and modified for this 2 different ways of storing the information.” Surely I must be missing something but I don’t see why that would be the case. Is there any code in Hugin that actually reads the display window, *and* would be negatively affected if it became correct? We have established that Hugin writes the pixel data that it should write to the EXR and that the data window reflects that. What would be the drawback of also setting the display window to that same window, if it is indeed the window that programs are supposed to use? I believe that this is the only change that would be required to solve the problem. “The current behavior of Hugin is consistent for TIFF and EXR.” Is it, though? When I export the same project as a TIFF, I get a 5242×3914 image (which corresponds to the cropped dimensions) with offset 0.17, 0.26. That does not resemble the properties of the exported EXR file. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: Opinion Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
> I believe that darktable is correct according to “Testing Other OpenEXR > Viewers” I think it is only correct when using darktable as viewer only. But as soon as you process the image, the data outside of the display should not be disregarded. Maybe Darktable should provide an option to use display or data window (as exrdisplay). The current behavior of Hugin is consistent for TIFF and EXR. If we would change it for EXR as you propose this would be different for both file formats which I don't like because then all place where images are loaded or saved would be checked and modified for this 2 different ways of storing the information. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: Opinion Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
I believe that darktable is correct according to “Testing Other OpenEXR Viewers” (https://www.openexr.com/documentation/OpenEXRViewers.pdf page 4): “The image should be cropped for files where the data window extends outside the display window, and padded with pixels of an appropriate background color for files where the display window extends outside the data window.” (As a side note, GIMP’s handling of OpenEXR is broken in other ways, for example it doesn’t interpret alpha as premultiplied like it should.) The “Technical Introduction to OpenEXR” (https://www.openexr.com/documentation/TechnicalIntroduction.pdf) says on page 6 that “For most images, in particular finished frames that will be delivered to the customer, the data window is the same as the display window, but for some images that are used in producing the finished frames, the data window differs from the display window.” Could we then consider setting the display window to the data window? If, as you say, the data window already contains exactly the data that is supposed to be displayed, then I don’t really see a reason not to (correct me if I am wrong). It would make all the aforementioned software agree. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: Opinion Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
Hugin calculates and saves only data inside the crop area. This is stored in OpenEXR as data window as written in the spec. So there are different ways to interpret the window sizes: Luminance HDR, Gimp, Picture, Hugin using the data window size. And darktable shows the display window size... So I don't see darktable as reference either... ** Changed in: hugin Status: New => Opinion -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: Opinion Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
Re: “If darktable shows only a black border on the left and top then it ignores the display window and is using only the offset of the data window. Otherwise it should also show a black border on the right and bottom.” Sorry, I should have made it clearer that my exrheader output was for one of the intermediary images. The final merged image (which is what I opened in darktable) has the same lower right corner for the data and the display window: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5292 3991) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: New Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
That, or if it’s only going to write the data inside the crop, then set both data and display windows to the crop. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: New Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
Just to clarify, I am not suggesting to simply write a different data window while writing the same data that Hugin currently does. I am proposing for Hugin to write all the data that it actually has (i.e. the canvas), and from that, set the data and display windows accordingly. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: New Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
> The spec states clearly that the data window describes the area which has data, which is how Hugin treats it. The point is that it’s not clear to me that this is how Hugin treats it. To me, it seems obvious that the crop size is supposed to indicate what should be visible in the final image. Why, then, does that end up as the *data* window and not the display window? And why does the canvas size, which is always a superset of the crop (the GUI enforces it), ends up as the display window? That means that there will pretty much always be a black border, regardless of how completely darktable displays it. > Luminance HDR displays such a OpenEXR without problems (without black border). I don’t think that Luminance HDR should be used as a reference given that it does not implement support for a display window smaller than the data window. The only use of the display window is to check whether to throw "No support for OpenEXR files DataWindow greater than DisplayWindow" (src/Libpfs/io/exrreader.cpp). ** Changed in: hugin Status: Invalid => New -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: New Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
The spec states clearly that the data window describes the area which has data, which is how Hugin treats it. So switching data and display window as you propose would clearly violate the spec. (Or Hugin would required to save a lot of black pixels with no information but increased file size). The behaviour of OpenEXR data window/display window is analogous how Hugin is using cropped TIFF images. Luminance HDR displays such a OpenEXR without problems (without black border). If darktable shows only a black border on the left and top then it ignores the display window and is using only the offset of the data window. Otherwise it should also show a black border on the right and bottom. ** Changed in: hugin Status: New => Invalid -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: Invalid Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
It technically conforms to the spec, but I don’t think it properly reflects the data inside. The black border when importing the file into darktable is an indication of that. ** Changed in: hugin Status: Invalid => New -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: New Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
>From the OpenEXR documentation >(https://www.openexr.com/documentation/ReadingAndWritingImageFiles.pdf): "An OpenEXR image may not have pixel data for all the pixels in the display window, or it may have pixel data beyond the boundaries of the display window. The region for which pixel data are available is defined by a second axis-parallel rectangle in pixel space, the data window." Hugin's notification is like the example on page 7 (top figure) in the linked documentation. So I think that the Hugins current notification is right and conforms the spec. ** Changed in: hugin Status: New => Invalid -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: Invalid Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1865333] Re: dataWindow and displayWindow look swapped in generated OpenEXR files
In case it’s useful information, that’s with Hugin 2019.2.0.b690aa0334b5 on Arch Linux with OpenEXR 2.4.1. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1865333 Title: dataWindow and displayWindow look swapped in generated OpenEXR files Status in Hugin: New Bug description: When exporting a high dynamic range image with a crop as an OpenEXR file, the cropped dimensions end up as the dataWindow and the canvas size as the displayWindow, which seems like it’s the wrong way around. When imported back into darktable, the image has a black border on the left and at the top. Export settings: https://i.imgur.com/TFmA6zP.png (also attached) exrheader output: dataWindow (type box2i): (51 78) - (5292 3991) displayWindow (type box2i): (0 0) - (5345 4070) This happens on intermediary remapped files too, not just the final merged output. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1865333/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
