hugin-devs team mailing list archive

[Sami Boukortt <1865333@xxxxxxxxxxxxxxxxxx>]

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