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
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 co
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 th
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 dis
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 t
> 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
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 Hugi
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 displayWind
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 th
I encounter this problem with the attached .pto file with Nona set to
the default of “Save cropped images” and the HDR merge mode set to
“Average slow” or “De-ghosting (Khan)”. Unchecking the Nona cropping
option makes “Average slow” and “De-ghosting (Khan)” work properly, and
“Average” always work
10 matches
Mail list logo
