Bug 297804

Which original image format, and which target image format ? Do you take a look into Setup Rotation page ? Which 2.6.0 beta release you use ?

Gilles Caulier

I'm using Digikam 2.6.0beta3. Load and save jpeg.
Yes, I tried several combos.

Rotate by changing the content (default) works as I described.
Rotate by only setting a flag - same as above.
Deselect the checkbox "set orientation tag to normal" causes opposite behaviour: "save" works fine (physical orientation and exif tags are unchanged): "save as" changes orientation (the image is rotated, but the exif tag is left unchanged).

Can you confirm that the image which is displayed wrongly orientated in digikam after a save is actually correctly displayed in another image viewer (e.g. gwenview)?
I believe the problem is that the rotation flag in the database is not reset.

You are right. In the ImageInformation table there is a field called "orientation". Its value is not updated when the image is saved with "save".

The original image is in landscape and the exif orientation flag is left,bottom (portrait).
I reloaded the saved images with Gimp, which has auto-rotation disabled.

"Set orientation tag to normal" is enabled.
"Rotate by changing the content" is enabled.

"Save": Pixel data is portrait, exif flag is landscape, orientation field==8.
"Save as": Pixel data is portrait, exif flag is landscape, orientation field==1.

Git commit 3ba18cfdd0bbb11f383db45ff7826750af7b3ff7 by Marcel Wiesweg.
Committed on 22/04/2012 at 19:00.
Pushed by mwiesweg into branch 'master'.

Use FileActionMngr to copy attributes in ImageWindow.
Add code to reset the database rotation flag in case of replacing a preexisting file.

M  +2    -0    utilities/imageeditor/canvas/dimginterface.cpp
M  +27   -12   utilities/imageeditor/editor/imagewindow.cpp

http://commits.kde.org/digikam/3ba18cfdd0bbb11f383db45ff7826750af7b3ff7

The commit should fix the problem

reopen if problem persists

I have a similar problem, so I'm afraid reopening the bug might be in order.

I've noticed this both in 2.6.0 and 2.9.0. I'm 99 % sure this still worked in 2.5.0:

If a Nikon NEF raw file in portrait orientation is edited by an external program so that rotation of the full-size jpeg preview (and exif) is changed (to top, left), digikam does NOT update it's internal orientation flag when it notices that the file has changed. Strangely enough, it does update the orientation information in the XMP sidecar (after making a metadata change which triggers updating the XMP sidecar, for example changing the rating).

The problem persists even if I copy or rename the image, either in digikam or externally, probably because digikam notices that the hash of the "new" file is found in database, so it just copies the record in the database.


The result is that edited portrait images are shown as landscape, since digikam still rotates them when it shouldn't.

Normally, a scan on file modification does not touch the orientation which may be user-edited.
I started to write code which updates the orientation if width/height changed as well, indicating a physical change. I stopped that when I saw a complication which I dont remember right now. There are lots of cases to consider. Not to speak of the added complexity of your RAW files with embedded previews.

Marcel,

I understand that you don't want digikam to alter image orientation if it has been changed by the user. However, I find it questionable if digikam does not update its own metadata if metadata of the image changes (and user has NOT overridden orientation in digikam). This causes conflicting metadata which can only confuse users (like me).

The main reason I'm currently using digikam is the fact that it does not force me to do all my workflow in digikam. I'm free to edit my pictures using different software and use digikam only for organization and metadata management. That's why i'm not using Lightroom, for example.

About updating orientation if width/height is changed: I'm against all sort of heuristics to solve these problem, since there are always corner cases which work wrong or unintuitively (consider a square image where width=height, where change would not be detected by your heuristics, if original image is rotated).

What about the following solutions to the problem?

1) Digikam remembers whether orientation has been manually changed in digikam. If yes, changes in file's orientation metadata do not affect digikam, otherwise orientation is updated if it changes in the file

2) If orientation is changed in digikam, digikam remembers both the new orientation and the original one. If orientation in the file is changed, digikam can detect this and update its own orientation. As long as orientation in the file is the same as the original, digikam does not update its own orientation data.

I think 1) could even be implemented without affecting digikam's current database schema. Orientation is now coded as one integer in digikam4.db. You could use an extra bit (or the sign of the number) to flag that orientation has been changed by the user. Then of course routines reading that information would have to be changed so that the flag is stripped away when using the actual orientation.

Anything touching the interpretation of the orientation field does not require a schema update, but is nonetheless completely backwards incompatible. (means you can't use your converted database with a prior version - we do this very rarely, only every few years).

Setting a property when orientation is changed manually seems a possible solution, but there's a drawback with files out there which were already changed manually - a lot of rotation information would be lost suddenly if a user did some unrelated editing.

You've seen the problems:
- we dont know if anything of the metadata was changed, we only see "the file" was edited
- we dont store the user-edited rotation differently from the one read from the file

Essentially, we treat rotation like all other metadata: Manual changes outside digikam need to be applied by re-reading metadata from file to db. No question that this tool should provide finer-grained control over which fields to read.

I understand your concern about backwards compatability.

But about "we treat rotation like all other metadata": there's metadata and then there's metadata. Most metadata is data *about* the image (shutter speed, date, gps, etc) and is not needed for interpreting the image itself. Then there's metadata that's not "meta" in the strict sense but is needed for correctly rendering the image. Image orientation belongs to this group, but so does at least icc profile (I can't list any others from the top of my head). This metadata needs to be correct to actually show the image.

If such essential metadata changes when the image itself is changed, digikam definitely *should* update the metadata as well, otherwise updating the image itself is pointless. If I edit a jpeg and change its color space from sRGB to ProPhotoRGB, the result would be catastrophic if digikam would still render the edited image as sRGB. The same applies to orientation. The only difference there is that digikam allows changing the orientation without actually "editing" the image and without updating the image file.

pochini,

Outside the discussion about metadata management open by Matti, the original problem about orientation is solved now using digiKam 3.5.0 ?

Gilles Caulier

It's ok now.