Images rotated on export in 1.7.1

First up, hats off to @agriggio, ART is an excellent piece of work, and it’s ease of use and more importantly results have enabled me to avoid the Adobe shackles (I tried hard to come to terms with Darktable, but just couldn’t get consistent results out of it)

I had to reinstall my laptop at the weekend after a Mint upgrade ate itself, and installed 1.7.1 from the appimage. Processing is working fine, but when exporting portrait format photos to JPEG, they’re rotated left by 90 degrees - all else appears to be fine.

To check, I installed 1.2 from the PPA (latest version there) which I had been using. This of course couldn’t read the 1.7.1 .arp file, but I quickly redid the edit and exported the result , which was fine. I next tried the same image again in 1.7.1 (the older .arp being readable) and exported the image with no further changes, and it came out rotated.

Looking at the the EXIF using exiftool, the 1.7.1 version has the following:

Orientation : Rotate 270 CW

whereas the 1.2 version didn’t include the Orientation field at all. Landscape format photos from 1.7.1 have:

Orientation : Horizontal (normal)

The files are RAF from a Fuji X-H1 (Fuji 10-24mm lens), and the Orientation: Rotate 270 CW is present in the source portrait files. Setting Orientation to 1 (Horizontal) for the affected (exported) images renders them correctly so I suspect the image is rendered on batch export with any rotation pre-applied (plus any further rotation in the editing), but the EXIF orientation then overcompensates when displayed. I’ve looked for a setting to turn it off, but can find none other that possibly rotating the images in the editor to compensate, but this would screw up editing

Hi,
try checking this:

Screenshot from 2021-01-06 13.31.16

Maybe you have it set to “copy unchanged”?

I didn’t have it selected, but changing it did nothing unfortunately, I tried the following:

  1. Leaving metadata list as is (just changing the dropdown)
  2. Unchecking Orientation
  3. Could find no way to change orientation value - editing wasn’t allowed
  4. Creating a profile by hand end excluding the Orientation tag then applying it on export

One thing I notice in the Metadata section in the .arp - in 1.7.1 the ExifKeys is populated regardless of the value of Mode. In 1.2 when Mode=0 (pass through) ExifKeys is absent, but the metadata is correct in the target image.

As a workaround I can probably throw together an inotify script to strip the tag from exported images, but I want to make sure I’m not missing something obvious first

I’ll take a closer look then

Hi @JMcL, can you share your .arp? I tried reproducing but failed…

Sure no problem - I’ll do it soon as I get back to the laptop. Will I share the raw file as well?

I’ll also try the appimage later on my desktop to see if I have the same issue, and I’ll try to have a look at older Panasonic and Canon raws to see if it’s just a Fuji issue

the more data you can share, the better

I’ve run a few tests and am putting the files together, but out of curiousity decided to see if it happened in my desktop (running Ubuntu 20.04). The image renders without setting the Orientation field even when I copy across the .arp file from the laptop. The field isn’t set in the output

I wonder is there something odd in the Mint environment? It’s a fresh install of Mint 20 (see below) and after Digikam (7.1.0 appimage), ART was pretty much the first thing on there.

Distributor ID:	Linuxmint
Description:	Linux Mint 20
Release:	20
Codename:	ulyana

I’ll put the files together anyway and share them later tonight, but if there’s anything in particular I can look at that might be of help, let me know

Are you sure you are not overwriting the arp from the queue? There’s an option to apply an extra profile on export from the queue, make sure you have that unchecked to understand if that is the culprit (or alternatively, try saving directly from the editor, without going through the queue)

No, the arp definitely isn’t being overwritten - I have it unchecked, and I export to a different location at any rate. I did try saving from the editor, but with the same result.

I’ve put the files together and uploaded them to Dropbox, with the results of various combinations:

  • Top level - raw file
    • 1.2/ - jpg and arp from version 1.2 PPA (metadata “Copy unchanged”)
    • 1.7.1/ - jpg and arp from version 1.7.1 Appimage (metadata “Copy unchanged”). Also includes EXIF from rendered jpg and the same rendering under 1.7.1 on a Ubuntu 20.04 desktop (from exiftool filename)
    • 1.7.1_apply_mods/ - jpg and arp from version 1.7.1 Appimage (metadata “Apply modifications” with all “Orientation” fields unchecked).

What’s very curious is that the two outputs from exiftool on Mint and Ubuntu are radically different. I’m not very familiar with Appimages, but I think I’m right in saying that all dependencies are baked in, so differing versions of exiftool/exiv2 etc. shouldn’t be an issue. There’s also a significant difference in size of the resulting jpegs - the laptop one is around 3.9Mb, the desktop <3Mb. While on the face of it the processing parameters (JPEG quality etc) are the same, there’s obviously something different. I’ll try to dig into the differences between the two tomorrow to see if anything stands out

1 Like

I just tried and your 1.7.1 arp works as expected for me (with the current master)… :man_shrugging:
I will try again with the appimage, maybe there’s an issue there?

It’s very strange. It only happens with the Appimage on the Mint laptop - the same Appimage performs as expected on the Ubuntu desktop, which makes me suspect it must be something to do with the Mint environment. I know the Appimage should have all the dependencies baked in terms of libs etc, but are there any calls out to external tools (if this is even possible)? Mounting the appimage i can see exiftool and exiv2 are present in the file. I had a quick look at the source also and exiftool has a path built up for it but I assume this will point to the packaged version.

I’ll try to look closer at what the desktop is doing differently later on as I only had time to do a quick test yesterday - I’m scratching my head as to why the written EXIF is so different between the two.

Ok. I also tested the appimage in the meantime, and as expected it works here…
BTW, exiftool is only used for formats not supported by exiv2, so for writing JPGs only exiv2 is used, which is linked into ART (so no external binary needed for that…)

Hi Alberto, apologies for the delay, I didn’t get a chance to do any more proper digging over the weekend.

Anyway, I think I’ve narrowed it down. It looks like it might be linked to the XMP file coming out of Digikam. I copied the files I’d been working on from the laptop to the desktop, tried to export some of the portraits and they were rotated.

Anyway, if the XMP is removed, the image exports correctly. I hadn’t included the XMP file in the test case I put together the other day, but I’ve uploaded it now alongside the .raf. I haven’t had a chance to dig into it deeply, and it may well turn out to be a Digikam issue in the end, but if it allows you to reproduce the issue, it may at least show where the issue lies.

For reference, I’m using Digikam 7.1.0 from the Appimage on the laptop (which is where the metadata originates).

I can investigate further if nothing jumps out at you from the XMP alone

Hi,

Ah! That might very well be indeed, if you have metadata synchronization set to anything other than “off” here:

@JMcL, should be solved now, thanks for your help!

Belated thanks for that Alberto, and no problem - glad I could contribute a little