Project

General

Profile

Feature #9346

Importing Lightroom: Not applying rotation

Added by Nikolaus Krismer about 6 years ago. Updated about 6 years ago.

Status:
Fixed
Priority:
Medium
Assignee:
Category:
Darkroom
Target version:
-
Start date:
04/08/2013
Due date:
% Done:

100%

Affected Version:
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I just installed the new release (v. 1.2) of darktable.
Since I was really looking forward to the new "import from lightroom" plugin tried it immediately.

Although it seems that some of the metadata from the xmp file is used, the rotation does not work.
I changed the orientation of the image using lightroom from landscape to portrait (using cw rotation 3 times).

I found out that the rotation applied by lightroom is stored in the xmp file using the tag "tiff:Orientation" (with a value of 8).
When using exiftool to read the xmp the following can be found:

[niko@laptop Documents]$ exiftool P4010391.xmp | grep Rotate
Orientation                     : Rotate 270 CW
Perspective Rotate              : 0.0

The message shown in darktable indicates that rotation was applied and since the blog entry says that rotation is fully compatible this seems like a bug to me.
So I would recommend to either change the shown import message (only show "rotation applied" if there was some rotation applied) or to apply the correct rotation from the xmp tiff tag (or better: both).

In the xmp file created by darktable (.orf.xmp) the orientation information is completely missing ;-(
I also attached my test files, so it can be used for fixing this bug.

Niko

P4010391.orf - RAW-image (11.1 MB) Nikolaus Krismer, 04/08/2013 12:24 PM

P4010391.xmp - XMP-file (created by lightroom - includes the orientation tiff tag) (6.46 KB) Nikolaus Krismer, 04/08/2013 12:24 PM

P4010391.orf.xmp - XMP-file (created by darktable 1.2 - does not include orientation information) (8.84 KB) Nikolaus Krismer, 04/08/2013 12:24 PM

P4010369.orf - RAW-Image crashing darktable 1.2 (11.4 MB) Nikolaus Krismer, 04/08/2013 03:04 PM

P4010369.xmp - XMP-file (created by lightroom - crasehs darktable - including tiff:Orientation and has crop) (3.39 KB) Nikolaus Krismer, 04/08/2013 03:04 PM

darktable_bt_OL8DVW.txt Magnifier - Darktable-Backtrace file created after crash with image P4010369 (59.9 KB) Nikolaus Krismer, 04/10/2013 10:34 AM

darktable_bt_OLT6VW.txt Magnifier - Backtrace from darktable-cli (7.67 KB) Nikolaus Krismer, 04/26/2013 11:57 PM

History

#1 Updated by Jérémy Rosen about 6 years ago

  • Assignee set to Pascal Obry

Assigning to pascal since he's the one that knows lightroome

#2 Updated by Pascal Obry about 6 years ago

  • Category changed from General to Darkroom
  • Tracker changed from Bug to Feature

I confirm, but this is not a bug but a missing feature. Orientation is not currently supported by the Lr import module, only rotation is. That is, if there is no crop/rotation in Lr the orientation is not taken into account. Probably something we want to support at some point. I'll keep this as a feature request.

#3 Updated by Nikolaus Krismer about 6 years ago

Ok... I did not know that there is a difference between rotation and orientation (sine I rotated the image in lightroom I'm a bit confused that things get saved as orientation, but i guess that this is a lightroom issue - not a darktable one).

FYI: The tiff:Orientation tag is described as follows (taken from http://www.awaresystems.be/imaging/tiff/tifftags/orientation.html):

The orientation of the image with respect to the rows and columns.
The specification defines these values:
1 = The 0th row represents the visual top of the image, and the 0th column represents the visual left-hand side.
2 = The 0th row represents the visual top of the image, and the 0th column represents the visual right-hand side.
3 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual right-hand side.
4 = The 0th row represents the visual bottom of the image, and the 0th column represents the visual left-hand side.
5 = The 0th row represents the visual left-hand side of the image, and the 0th column represents the visual top.
6 = The 0th row represents the visual right-hand side of the image, and the 0th column represents the visual top.
7 = The 0th row represents the visual right-hand side of the image, and the 0th column represents the visual bottom.
8 = The 0th row represents the visual left-hand side of the image, and the 0th column represents the visual bottom.

The specification considers this a baseline tag, but does add that support for orientations other than 1 is not a Baseline TIFF requirement.
LibTiff defines these values:
ORIENTATION_TOPLEFT = 1;
ORIENTATION_TOPRIGHT = 2;
ORIENTATION_BOTRIGHT = 3;
ORIENTATION_BOTLEFT = 4;
ORIENTATION_LEFTTOP = 5;
ORIENTATION_RIGHTTOP = 6;
ORIENTATION_RIGHTBOT = 7;
ORIENTATION_LEFTBOT = 8;

However, I am not sure if one has to take care of the orientation BEFORE applying a crop or AFTER applying a crop (and other transformations as well).
It would be easy for me to take care of orientation by myself if AFTER is true...
...if BEFORE is true i would suggest to fix this very soon, because an image crop is incorrect then, isn't it (shouldn't implementation be easy just by converting the eight orientation values to a rotation value)?

Although I did some "google-research" I did not find out if orientation should be applied BEFORE or AFTER crop... does anyone know this?
I am starting to think that orientation has to be used BEFORE crop, since one of my pictures cause a darktable crash when used with the xmp containing crop and orientation (maybe there is something different in the xmp file causing the crash, but i guess this is related to crop and orientation...).

#4 Updated by Pascal Obry about 6 years ago

I have added support for the orientation module, can you test the lr-import-orientation branch on Git?

Thanks.

#5 Updated by Nikolaus Krismer about 6 years ago

Just downloaded, compiled and installed darktable from GIT as described on the website (version 1.3-31~ga78b31b).
But it seems like nothing has changed (no orientation/rotation change when importing a raw file, still crashing with raw file attached in comment #4).
Is there anything else I have to do??

#6 Updated by Pascal Obry about 6 years ago

You need to:

- remove image from lr collection
- remove the P4010391.orf.xmp file
- reimport the image

If you still have an issue in this case let us know.

#7 Updated by Pascal Obry about 6 years ago

I have double checked that importing P4010369.orf/P4010369.xmp in dt is fine. No crash on my side!

#8 Updated by Nikolaus Krismer about 6 years ago

Just tried that again (with a fresh git pull and a recompile).
Still the same result... no orientation/rotation change and still a crash when working with P4010369.xmp.

I did the three steps you described, but since I am using fedora linux 18 and there is no Adobe LR installed I skipped step 1.
Is there some more information that I can provide to help in fixing this?

#9 Updated by Pascal Obry about 6 years ago

I see, the version you downloaded is not the proper one: a78b31b is on master.

My branch lr-import-orientation is not yet merged. You can get the correct sources here:

https://github.com/darktable-org/darktable/archive/lr-import-orientation.zip

Can you test this branch?

#10 Updated by Nikolaus Krismer about 6 years ago

I also tested your branch (sorry... did not mentioned that I tested on master branch and lr-import-orientation branch)
The version I tested on your branch is: 1.3+21~gd439522 (which also does not work... things do not get rotated and darktable still crashes).

I can also see the changes in the src folder of the file "src/develop/lightroom.c"...

...however, things are still a bit wired... I can compile from your branch, but not using your zip file (build.sh script stops after the message "No saxon XSLT processor and/or no docbook saxon extension library found. Xslt processor saxon not found. HTML usermanual will be built with xsltproc; expect usermanual with inconsistent screenshot and image dimensions." while the script from your branch just continues after this message (where is the difference??) I tried to install a XSLT processor and the docbook-saxon-extension, but i guess that they can not be found on fedora 18...

Today I noticed that I also had an old version of darktable (v 1.2) installed, but even after removing it things do not work.
Is there anything else I can try?

#11 Updated by Pascal Obry about 6 years ago

Maybe you can try with:

$ darktable --library /tmp/newdb.db

This will use a new empty library. Then try importing the files again.

#12 Updated by Nikolaus Krismer about 6 years ago

Just tried it with a new DB (and deleted the .orf.xmp files before importing).
Still the same result: Images do not get rotated and darktable crashes for image P4010369.

I applied the backtrace of the crash. Maybe this helps a bit.

#13 Updated by Pascal Obry about 6 years ago

You problem seems a cache issue not a lr import one. I'm not sure what's the best solution. Maybe destroy the cache?

$ rm -fr ~/.cache/darktable

But please do not do that until someone else confirm that won't break anything.

I have also fixed the orientation support for landscape images, so please try with the latest code in the branch. If you can test with different images (portrait / landscape) and different orientation it would be nice. It is not easy to get this right...

Thanks.

#14 Updated by Nikolaus Krismer about 6 years ago

Updated files from your branch and recompiled.
The image "P4010391" now gets rotated on import. Great work :-)
But when importing image P4010369 darktable still crashes.

Here is what I do when starting darktable:

[niko@laptop bin]$ rm -rf /home/niko/.cache/darktable/
[niko@laptop bin]$ rm -rf /tmp/newdb.db 
[niko@laptop bin]$ rm -rf /home/niko/Images/*.orf.xmp
[niko@laptop bin]$ ./darktable --library /tmp/newdb.db

I will try this with different images as soon as possible (I do not have many images here on my laptop, so this won't be before the weekend)

#15 Updated by Pascal Obry about 6 years ago

Good to see that the orientation works now :)

The procedure you use for testing seems good to me.

Do you have OpenCL activated? If so, can you run without this enabled, it may explain why I do not see the crash...

#16 Updated by Pascal Obry about 6 years ago

BTW, I found some time to fire-up Lightroom and do some testing and I have adjusted orientation for landscape pictures. Be sure to test the new branch.

#17 Updated by Nikolaus Krismer about 6 years ago

OpenCL is activated in darktable. But it seems that I can not disable it using the darktable properties dialog.
In general there seems something wrong to me. When using the darktable preferences dialog opencl is activated (and can not be disabled), but when starting darktable with the command

./darktable --library /tmp/newdb.db -d opencl

I get the following output (which indicates that opencl is not working):
[opencl_init] opencl related configuration options:
[opencl_init] 
[opencl_init] opencl: 1
[opencl_init] opencl_library: ''
[opencl_init] opencl_memory_requirement: 768
[opencl_init] opencl_memory_headroom: 300
[opencl_init] opencl_device_priority: '*/!0,*/*/*'
[opencl_init] opencl_size_roundup: 16
[opencl_init] opencl_async_pixelpipe: 0
[opencl_init] opencl_synch_cache: 0
[opencl_init] opencl_number_event_handles: 25
[opencl_init] opencl_micro_nap: 1000
[opencl_init] opencl_avoid_atomics: 0
[opencl_init] opencl_omit_whitebalance: 0
[opencl_init] 
[opencl_init] trying to load opencl library: '<system default>'
[opencl_init] could not find opencl runtime library 'libOpenCL'
[opencl_init] no working opencl library found. Continue with opencl disabled
[opencl_init] FINALLY: opencl is NOT AVAILABLE on this system.
[opencl_init] initial status of opencl enabled flag is OFF.
[mipmap_cache] cache is empty, file `/home/niko/.cache/darktable/mipmaps-db71811a3e92a9ba3f00e7e113bab93aadb40cd8' doesn't exis

Even when starting with opencl disabled using the following command, the settings dialog indicates that opencl is activated (and can not be deactivated)
./darktable --library /tmp/newdb.db --disable-opencl

#18 Updated by Pascal Obry about 6 years ago

Fine, it means that OpenCL is not enabled. Then I have zero idea about the crash since I cannot reproduce.

#19 Updated by Nikolaus Krismer about 6 years ago

Just tried importing the image P4010369 on a newly created fedora 18 virtualbox.
Same behaviour... darktable crashes ;-(

What I actually wanted to do is to use darktable for command-line raw conversion with rotation, clipping and orientation applied. This does not work either. After each image darktable-cli crashes.

Maybe the backtrack from darktable-cli helps a bit. I appended a backtrace file

#20 Updated by Pascal Obry about 6 years ago

  • % Done changed from 0 to 50
  • Status changed from New to In Progress

Can't this be because the VM has not enough memory?

Some questions:

1. can you import this image without the Lr .xmp around?

2. can you import this image in a non VM Windows with and without the .xmp?

At least since the orientation is now properly implemented I'll merge this part.

Thanks.

#21 Updated by Nikolaus Krismer about 6 years ago

Increasing the memory did solve the problem in the VM.

Regarding the darktable crash:
1) Yes... I can import the image without the xmp file around
2) Yes... I can import the image in a windows (not a virtualized one) with and without .xmp (in lighroom 4)

Great to here that the orientation import will become part of the next dartable release :-)

#22 Updated by Pascal Obry about 6 years ago

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

Good to hear that this was a memory issue! Closing this ticket then.

#23 Updated by Nikolaus Krismer about 6 years ago

Shouldn't that feature be part of the master branch now?

I tried to import an image into darktable today (freshly build from git master branch), which was not correctly rotated...
(just wanted to ask if this should already work before filling a new ticket)

#24 Updated by Pascal Obry about 6 years ago

Yes, and you said on 2013-04-10 that it was working for you too (see above).

So maybe another issue. Be sure to remove dt .xmp when you reimport to be sure that the lr import is done.

If you still have an issue, please open a new ticket and file an image + lr .xmp to reproduce. Thanks.

Pascal.

#25 Updated by Nikolaus Krismer about 6 years ago

Hmm... just double-checked. Rotation still works with the image supplied here (so no re-open or something is needed).
However, it does not work with the image I tried today. I will open a new ticket for that issue and provide some data.

Also available in: Atom PDF