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
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...
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
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
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
> 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.
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).
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
>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
Public bug reported:
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
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
11 matches
Mail list logo
