Project

General

Profile

Bug #9423

Orientation is not correctly applied for all images

Added by Nikolaus Krismer almost 7 years ago. Updated almost 7 years ago.

Status:
Fixed
Priority:
Critical
Assignee:
Category:
Darkroom
Start date:
05/15/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Although orientation is applied when importing images with .xmp files (created by lightroom), the rotation is not always applied.
Taking orientation into account works for the images applied in Ticket #9346 (image P4010391.orf with P4010391.xmp), but not for the image applied here.

I do not know where the exact differences are, since both xmp files contain the tag "tiff:Orientation=8", which can easily be proved using exiftool

[niko@desktop Images]$ exiftool P4010391.xmp | grep Rotate
Orientation                     : Rotate 270 CW
Perspective Rotate              : 0.0
[niko@desktop Images]$ exiftool P3190333.xmp | grep Rotate
Orientation                     : Rotate 270 CW

Maybe there is still something wrong/missing in the orientation/rotation code.
Can someone please have a look at this?

Niko

P3190333.orf (12.8 MB) P3190333.orf Image of a spanish bar in Berlin Nikolaus Krismer, 05/15/2013 03:37 PM
P3190333.xmp (3.06 KB) P3190333.xmp XMP-file (created by lightroom) Nikolaus Krismer, 05/15/2013 03:37 PM
P3190333_orig_modified.xmp (3.06 KB) P3190333_orig_modified.xmp Original XMP with the xmpMM:HIstory-Tag removed (removed by hand; not using exiftool) Nikolaus Krismer, 05/15/2013 04:32 PM
P3190333_orig_unmodified.xmp (3.39 KB) P3190333_orig_unmodified.xmp Original XMP (as stored by lightroom) Nikolaus Krismer, 05/15/2013 04:32 PM
argsExiftool.txt (1.97 KB) argsExiftool.txt Nikolaus Krismer, 05/15/2013 04:34 PM

History

#1 Updated by Pascal Obry almost 7 years ago

  • Target version set to Candidate for next patch release
  • Assignee set to Pascal Obry
  • Category set to Darkroom

#2 Updated by Pascal Obry almost 7 years ago

The issue seems that the .xmp is not the "common" (whatever that mean) format. In all xmp I have seen so far we have:

<xmpMM:History>
<rdf:Seq>
<rdf:li
stEvt:action="saved"
stEvt:instanceID="xmp.iid:2c019766-a546-6048-b0cd-66ce23053a76"
stEvt:when="2013-04-01T18:27:50+02:00"
stEvt:softwareAgent="Adobe Photoshop Lightroom 4.3 (Windows)"
stEvt:changed="/metadata"/>
</rdf:Seq>
</xmpMM:History>

But in this one we have only:

xmp:CreatorTool="Adobe Photoshop Lightroom 4.3 (Windows)"

In the main rdf node!!!

And in both .xmp I've compared we have as header:

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.5-c002 1.148022, 2012/07/15-18:06:45        ">

So same XMP version!!! How was this xmp generated?

#3 Updated by Nikolaus Krismer almost 7 years ago

Hmm... that is interesting.
This xmp file was created by lightroom.
Since there seems to be a problem with the xmpMM:History-Tag (see http://darktable.org/redmine/issues/9404#change-23018; causes darktable to crash on my systems) I also used exiftool to remove the xmpMM:History tag create a modified xmp from this one. I now see that for some reason (I do not know why) the original XMP has also been changed by exiftool (a backup xmp with extension xmp_orginal has been created).

I attached the unmodified xmp (P3190333unmodified.xmp).
I also attached the original xmp with the xmpMM:History-Tag removed (P3190333modified.xmp) that I use to prevent the crash when opening darktable.
With this xmp-file the image is still not rotated.

#4 Updated by Nikolaus Krismer almost 7 years ago

I also attached my configuration file, that I use when working with exiftool

#5 Updated by Pascal Obry almost 7 years ago

Should be fixed in the branch fix-lr-import-orientation.

If you are building from source can you test it?

#6 Updated by Nikolaus Krismer almost 7 years ago

Just tried it with the fix-lr-import-orientation branch.
But although I deleted the cache, darktable's library and any *.orf.xmp sidecar file, the image is not rotated on import.
I double-checked that I used the correct branch and the correct executable.

One interessting thing is that darktable does not crash anymore when using the unmodified xmp file (on master branch this causes darktable to crash while now only a black image is generated)... however, I am not sure if this is due to your change or some other chnage made in the meantime.

#7 Updated by Pascal Obry almost 7 years ago

I'm lost :( This is working on my side with the image you sent!!

When you import your images you should see a message on the center area listing the imported modules. What is the text? Is it said that the orientation is imported?

#8 Updated by Nikolaus Krismer almost 7 years ago

With the image from issue #9346 (P4010391.orf) I do see this message.
It says something like (translated from german): "Input profile, orienation and exposure was imported", so your module is listed for that image.

When using the image applied in this issue (P3190333.orf) I just see a message saying "working...", but without modules listed.
Hope this information helps a bit...

#9 Updated by Pascal Obry almost 7 years ago

When using the image applied in this issue (P3190333.orf) I just see a message saying "working...", but without modules listed.
Hope this information helps a bit...

Yes, this means that you are probably not using the proper executable since this is exactly what I have fixed. On my side I do have the orientation listed.

Or maybe your are using the stripped xmp?

Also, please test with darktable non translated, on the command line:

$ LANG=en_US.UTF8 darktable

(testing on another computer I just found out that my french version of darktable behave strangely!).

#10 Updated by Nikolaus Krismer almost 7 years ago

Ok... I now tried to start with LANG=en_US.UTF8.
Same result. I also think that I am using the correct executable.

I did a fesh make uninstall followed by a make instal in my folder /opt/darktable. I also removed all other branches (including master branch) from harddisk before.
The command "which darktable" gives "/opt/darktable/bin/darktable" (just as it did before... so I think that I am using the correct branch).

Calling darktable (after deleting darktable's cache and it's library) by
LANG=en_US.UTF8 /opt/darktable/bin/darktable P3190333.orf
behaves this way:
1) If the xmp file containing the xmpMM:History tag is part of the xmp file the message regarding the loaded modules is shown (and the modules include crop and rotate), but the "image" shown is all black with a dimension where height is much bigger than width.
2) If the xmp file used does not contain the xmpMM:History tag the image is shown, but not rotated (in this case there is no message shown that any modules have been loaded)

Does this information help? Is there anything I can try next?

#11 Updated by Pascal Obry almost 7 years ago

  • % Done changed from 0 to 10
  • Status changed from New to Confirmed

Thanks for the experiment.

What you described in 1 matches what I'm seeing wrong on my side. But this only occurs when using the french translated version and not the english one!

The second point is expected, a stripped xmp is not recognized as a lightroom xmp and no import is done.

For 1 I suspect that there is something wrong happening since the crop/rotate module has been changed. I'll have a look.

#12 Updated by Pascal Obry almost 7 years ago

I think I found the issue:

The output is from:

pc.cy = (float)atof((char )value);
printf ("CROP TOP (%s) %f\n",(char
)value, pc.cy);

That is, I output the string and the corresping converted value by atof():

$ LANG=fr_FR.UTF8 darktable

CROP TOP (0.03096) 0,000000
HAS CROP 1

$ LANG=en_US.UTF8 darktable

CROP TOP (0.03096) 0.030960

Looks like atof() expect a comma when LANG=fr_FR.UTF8! Testing on a simple C program does not exhibit such behavior and for sure this was working before as I have developed the lr import module with a french version of dt! So a regression somewhere... No idea at the moment!!!!

Anyone?

#13 Updated by Pascal Obry almost 7 years ago

  • System changed from Fedora/RHEL to all
  • % Done changed from 10 to 50
  • Priority changed from Low to Critical
  • Status changed from Confirmed to In Progress

Niko, can you try again the branch? I have just pushed a possible fix. I don't have the right setup at the moment to test on my side, but I believe this is fixed. Let me know.

#14 Updated by Nikolaus Krismer almost 7 years ago

Tried the import with the new version from you fix-lr-import-orientation branch.
Things work very well now. Rotation/Orientation is applied for the image applied in this issue and from issue #9346 (P4010391.orf).
There are other good news too... your change has also fixed issue #9404. I can now work with the xmpMM:History tag in the image (and xmp) applied there...

I would try to convert my whole image collection (which takes some time since I've got more than 10.000 images made with various cameras, various raw types (with and without xmp) or simple jpg files) as soon as both bugs are fixed. I will give some more feedback after this is done... but right now all I can say is that this issue is fixed for me.

Greatwork :-)

#15 Updated by Pascal Obry almost 7 years ago

Good to hear! Since I have made another fixes some minutes ago, can you tell me which SHA-1 is on top of the branch?

What the output for:

$ git log -1 fix-lr-import-orientation

Thanks.

#16 Updated by Nikolaus Krismer almost 7 years ago

Output of the command is

commit 056fc22ecc66031d3bb27e79e49c6ef372637181

#17 Updated by Pascal Obry almost 7 years ago

The latest version. So all is fine. Thanks.

#18 Updated by Pascal Obry almost 7 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed

Closing as this should be fixed.

Also available in: Atom PDF

Go to top