Bug #10721

Create HDR Rotated and cropped off area

Added by Joe Giampaoli over 4 years ago. Updated over 4 years ago.

Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git development version
hardware architecture:


I've never seen this before, but then this is the first time I create an HDR with vertical shots where I get strange results where the final merged HDR is rotated and with a black area cut off, if I apply rotate to the RAW's then the result is fine, I'm not sure if this has anything to do with the EXIF info in the RAW's My RAW's are DNG 1.1 created by CHDK, if you need them let me know, attaching screenshots so you can see differences.


Bad Result.png (266 KB) Bad Result.png Joe Giampaoli, 11/15/2015 04:08 AM
Good Result.png (264 KB) Good Result.png Joe Giampaoli, 11/15/2015 04:08 AM

Associated revisions

Revision 7b4623fb (diff)
Added by Roman Lebedev over 4 years ago

dt_imageio_export_with_flags(): apply flags before doing anything with the pipe. Fixes #10721.

It is possible to disable through those flags some iops, and
in HDR creation case, if we get dimensions before disabling iops,
for vertical images we end up with wrong image dimensions.
(or rather, with the wrong buffer orientation)

Revision 328dc283 (diff)
Added by Roman Lebedev over 4 years ago

Fix DT HDR orientation. Refs #10721

1. dt_exif_read_blob(): unset orientation only if not in DNG mode.
Since buffers are not flipped during raw import for some time,
and flip iop is not applied for HDR creation, image Orientation
still makes sense and need to stay.

2. dt_exif_write_blob(): apparently, even if image does not have any
EXIF data (like our HDR DNG's, right after writing), when we ask
exiv2 for it's exif, it probably assembles some defaults,
including orientation.
And thus, since exiv2 "found" orientation field, we do not write it.
Fix it by always writing our EXIF tags, even if that will override stuff.


#1 Updated by Roman Lebedev over 4 years ago

  • System changed from Debian to all
  • Affected Version changed from 2.0rc1 to git development version
  • % Done changed from 0 to 10
  • Status changed from New to Confirmed

Yeah, there is something internally wrong about HDR and non-horizontal images.

#2 Updated by Roman Lebedev over 4 years ago

  • Assignee set to Roman Lebedev

#3 Updated by Roman Lebedev over 4 years ago

  • % Done changed from 10 to 100
  • Status changed from Confirmed to Fixed

#4 Updated by Joe Giampaoli over 4 years ago

Roman Lebedev wrote:

Applied in changeset darktable|7b4623fb3a7b2486dd5908e2608f41936ac826b8.

Thanks for the fix! It's working!


Also available in: Atom PDF

Go to top