Importing Lightroom: Not applying rotation
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.
#2 Updated by Pascal Obry about 7 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 7 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...).
#5 Updated by Nikolaus Krismer about 7 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??
#8 Updated by Nikolaus Krismer about 7 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 7 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:
Can you test this branch?
#10 Updated by Nikolaus Krismer about 7 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?
#12 Updated by Nikolaus Krismer about 7 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 7 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...
#14 Updated by Nikolaus Krismer about 7 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)
#17 Updated by Nikolaus Krismer about 7 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
#19 Updated by Nikolaus Krismer about 7 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 7 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?
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.
#21 Updated by Nikolaus Krismer about 7 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 :-)
#23 Updated by Nikolaus Krismer about 7 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 7 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.