digiKam image orientation when exporting from darktable

[nosle]

Portrait images exported with darktable from raw files tagged in digiKam (.xmp) end up with the wrong orientation. Somehow the digiKam touched .xmp plays badly with darktable. The raw files have the correct orientation in darktable and the tags from digiKam are imported. The problem only occurs with exported jpg files.

Has anyone else had this problem?

The problem lies somewhere between darktable and digiKam but I posted in the darktable forum as the files look correct until exported from darktable.

[Morgan_Hardwood]

Include version numbers in your post.

[nosle]

darktable 2.4.4 digiKam 5.9.0

I can’t provide examples atm (on phone) but will if needed. It has been like this for a while I stopped using digiKam because of it. Wanted to make it work due to lots of people to tag.

[nosle]

Uploaded faked portrait (flower) with xmp files raw file and jpg to filebin

Filebin | vn9kwcrluu2az18t

Realised a flower is not ideal for showing orientation but you have to take my word for it being in portrait format.

hmm… seeing that filebin shows the image correctly perhaps it’s a geeqie bug?

Edit:
Looking at the exif I find the following:

Perhaps only Geeqie reads the xmp.tiff.Orientation tag. The question is how they got out of sync.

Edit: Exiftool output

$ exiftool -Orientation -a IMGP8328.*
======== IMGP8328.DNG
Orientation                     : Rotate 270 CW
======== IMGP8328.DNG.xmp
Orientation                     : Rotate 270 CW
======== IMGP8328.DNG.xmp.digiKam
Orientation                     : Rotate 270 CW
======== IMGP8328.jpg
Orientation                     : Horizontal (normal)
Orientation                     : Rotate 270 CW
    4 image files read

[nosle]

So what appears to happen is that the xmp.tiff.orientation tag is copied from the xmp sidecar into the jpg whilst the exif.image.orientation tag is set at export to top,left resulting in a jpeg with dual orientation tags. Depending on the viewer the image will be shown as landscape or portrait.

Note that the camera used in the example produces “native” DNG’s they are not the result of a conversion.

To me this does look like a darktable bug.

[houz]

@nosle

To me this does look like a darktable bug.

To me it looks like a bug, too. Please check if this file opens properly in digikam – I don’t have that so I can’t test myself.

[nosle]

I’m travelling atm and won’t be back at my workstation for at least 2 weeks. I’ll check then unless someone else does it before me.

[rasimo (Simon Frei (imsodin))]

That picture opens just fine in digikam.

[houz]

And the original one doesn’t for you?

[rasimo (Simon Frei (imsodin))]

Yes, it does, i.e. both your pic and the one from digiKam image orientation when exporting from darktable - #4 by nosle are shown as portrait. Didn’t check that before, wasn’t following too closely…
I am running a development version of digikam, but I am not aware of any changes in that regard since 5.9.0 (which is no guarantee).

[houz]

That indicates that the original problem isn’t reproducible.
I guess I’ll just push the change and @nosle can tell us if it helped when he is back.

[nosle]

Edit: missed that you produced the image with a patched version? Will leave the post below anyway.

Just to confirm what you did to produce the image above.

1 Dowload files from filebin link above
2 Rename IMGP8328.DNG.xmp.digiKam to IMGP8328.DNG.xmp (optionally backup the previous file)
3 Import IMGP8328.DNG alongside IMGP8328.DNG.xmp into darktable
4 Export jpeg and post https://pixls-discuss.s3.amazonaws.com/original/2X/f/fdb337acaa8cacc0d77cdcd179c40bf7f09d71b8.

correct? The keywords being in the file suggests you did follow the above procedure. So now I’m stumped

I tried with another computer using darktable just now and my file contains the following exif
So dual tags with different orientations. Hence shows landscape in Geeqie.

The file you uploaded shows the following exif according to Geeqie

So only the Exif.Image.Orientation tag indeed suggesting you get different results than I do. This is the exiftool output from the image I produced following the outline

$ exiftool -Orientation -a IMGP8328.jpg
Orientation : Horizontal (normal)
Orientation : Rotate 270 CW

This is the exiftool output on your image

$ exiftool -Orientation -a fdb337acaa8cacc0d77cdcd179c40bf7f09d71b8.jpg
Orientation : Horizontal (normal)

If i remember correctly Geeqie uses exiv2 so testing in both Geeqie and exiftool should cover any exif tool errors. The attached file is what my workflow produces for me.

Will download to see if the upload process alters exif.
Edit: nope the above image still shows landscape in Geeqie while yours don’t. Perhaps there’s a setting somewhere.

[rasimo (Simon Frei (imsodin))]

Wait, I thought we were talking about digikam? I just opened the two files in geeqie and indeed @houz’ one is in portrait, while @nosle’s is in landscape orientation.

There also seem to be MakerNotes that are not yet fixed by houz’ change (exiftool -a -G *filename* | grep -i orient):

original

[EXIF]          Orientation                     : Horizontal (normal)
[MakerNotes]    Level Orientation               : Rotate 270 CW
[MakerNotes]    Level Orientation               : Rotate 270 CW
[XMP]           Orientation                     : Rotate 270 CW

houz:

[EXIF]          Orientation                     : Horizontal (normal)
[MakerNotes]    Level Orientation               : Rotate 270 CW
[MakerNotes]    Level Orientation               : Rotate 270 CW

It seems geeqie takes xmp over exif, while digikam does it the other way around - therefore the issue doesn’t appear in digikam.

[nosle]

I think the level orientation is related to the sensor shifting horizon correction available in Pentax cameras.

Edit:
Not so sure

[houz]

So I conclude that the image is at least better than the original version and will push my changes. We can still remove those LevelInfo things when we find that they are wrong.

Edit: I already pushed them a while ago. I am getting old.