hugin-devs team mailing list archive

[Sami Boukortt <1865333@xxxxxxxxxxxxxxxxxx>]

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