Bug 137191

Created attachment 18497 [details]
part of the album window showing thumbs of raw images upside down

There have been several bugfixes concerning image rotation.
In particular, the two bugs mentioned above have been fixed by now.

Could you maybe try with a recent digikam 0.9.2-beta3 to see
if things have improved for you?

Many thanks in advance,

Arnd

sorry, I'm having trouble building beta3 on kubuntu feisty :-(

make[4]: Entering directory `/home/simon/src/digikam-0.9.2-beta3/digikam/libs/dmetadata'
if /bin/bash ../../../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../digikam/libs/dimg -I../../../digikam/digikam   -I/usr/include/kde -I/usr/share/qt3/include -I.   -DQT_THREAD_SUPPORT  -D_REENTRANT  -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE  -MT dmetadata.lo -MD -MP -MF ".deps/dmetadata.Tpo" -c -o dmetadata.lo dmetadata.cpp; \
        then mv -f ".deps/dmetadata.Tpo" ".deps/dmetadata.Plo"; else rm -f ".deps/dmetadata.Tpo"; exit 1; fi
dmetadata.cpp: In member function 'int Digikam::DMetadata::getImageRating() const':
dmetadata.cpp:216: error: passing 'const Digikam::DMetadata' as 'this' argument of 'bool KExiv2Iface::KExiv2::getExifTagLong(const char*, long int&)' discards qualifiers
make[4]: *** [dmetadata.lo] Error 1
make[4]: Leaving directory `/home/simon/src/digikam-0.9.2-beta3/digikam/libs/dmetadata'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/simon/src/digikam-0.9.2-beta3/digikam/libs'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/simon/src/digikam-0.9.2-beta3/digikam'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/simon/src/digikam-0.9.2-beta3'
make: *** [all] Error 2

Update libkexiv2, and all will be fine

Gilles

Look here :

http://www.digikam.org/?q=download/svn

... and especially the section "Install digiKam in your Home Directory"...

Gilles

Gilles Caulier wrote:
[bugs.kde.org quoted mail]

Sorry, I still cannot compile the software on feisty. The scripts don't 
work for me (even after I replaced the /home/fabien with $HOME) and the 
other instructions fail as well (stuck at compiling the libs, libkdcraw 
is missing a .moc (dcrawbinary.cpp:36:27: error: dcrawbinary.moc: No 
such file or directory)

I'll see again when a binary is available for feisty (I'm tracking the 
repository for feisty editions of digikam). This is not a blocker bug 
for me. So far, digikam is not more than a semi-convenient way of 
downloading images from my CF card. The rest of my workflow is 
commandline dcraw/convert/exiftool, gqview and gimp/ufraw. The only 
convenient part is that digikam downloading is offered at loading the CF 
card and that I can select which images to download and where to save them.

(See also my RAW workflow wishlist item 
http://bugs.kde.org/show_bug.cgi?id=142975 , I'll keep updating that 
with ideas if I get them)

Cheers

Simon

I'm now using 0.9.2-final and the problem is still there.

raw files usually have an embedded jpg "thumbnail", I guess this is used in digikam to show an image for a raw file, it may be usuful to have the thumbnail show up right side up, which may be determined from the stored exif info or it might be set manually. 

The problem is really that the right-mousebutton menu shows the option to rotate, but when this is used, an error occurs, since a raw file can't be rotated. So the solution to this bug is either not show the rotate option (or grey it) for raw images, or change the option to say "rotate thumbnail" for raw files and then store a rotation offset with the image metadata.

Cheers

Simon

Simon,

What's news about this file ? Are you tried digiKam 0.9.4 ?

Gilles Caulier

this is still not possible in an early 0.9.5-svn version.

When I rotate the raw file (which isn't possible) I get an error, and there is no option to rotate the icon/thumbnail of the raw file only.

Basically, just being able to set the rotation option for a file (raw or otherwise) would probably fix it, since I assume you do check the orientation in the exif info, if it is there?

Unfortunately, I haven't seen any new info about rotation information in Sony's A100 .ARW format...

Cheers

Simon

Marcel,

Look this entry. Do you remember my email some month ago about to only rotate thumb and not image as well ? 

Gilles Caulier

Can't find the mail right now, do you know the date?

Anyway, I think the problem is files for which we cannot edit the metadata, so we need to use the rotation flag stored in the database for it? So one thing is editing the rotation flag, second thing is reading it from the thumbnail creator. As usual it is a bit difficult as regards dependencies, but perhaps we keep that in mind if/when we redesign the thumbnail storage?

Marcel, 

> Can't find the mail right now, do you know the date?

Mail from me, december 2008 : "virtual rotation of image..."

>Anyway, I think the problem is files for which we cannot edit the metadata, so
>we need to use the rotation flag stored in the database for it? 

yes.

>So one thing is editing the rotation flag, second thing is reading it from the >thumbnail creator. As usual it is a bit difficult as regards dependencies, but >perhaps we keep that in mind if/when we redesign the thumbnail storage?

and yes...

Gilles

*** Bug 194800 has been marked as a duplicate of this bug. ***

Johannes,

This feature is fully relevant of new thumbs database introduced with 1.0.0.

If i'm not too wrong :

- thumbs are stored as well in DB.
- A flag in DB can be used to give informations about orientation.
- when thumbs is extracted to be displayed, flag is used to process rotation.

Marcel, can you confirm ?

Gilles

There is a rotation field in the main database which is filled from Exif info. This field is currently ignored.
And there is a rotation field in the thumbnail database which is also filled from Exif info at time of thumbnail creation. This one is used to rotate the thumbnail after loading it from the thumbnail database.

Why two fields? Because the first existed when we needed the second... We could fill the second from the first instead of reading the file metadata directly. To adjust a thumbnail rotation "virtually", both should be updated.

As I found out in 1.3.0 (and possibly even in previous versions) there's a way to rotate the preview: In German GUI it is Bild > Exif-Ausrichtung justieren > [...], so in English GUI it should be found in Image > Justify Exif Orientation > [...] (or something similar).

So I guess the solution is as simple as changing the EXIX orientation (as the menu entry above does) instead of trying to rotate the image itself.

It would be very nice if this would happen transparent for the user, so if he calls the "normal" rotation via the overlay menu, the context menu or the Image menu the EXIF orientation rotation should be used instead of real rotation for RAW images. This should happen without showing a disturbing warning or something; maybe a short non-disturbing/interrupting information in the status bar is useful.

A temporal workaround is it to set short cuts - at least for more experienced users.

But:
a) Most users won't even know that they can rotate by changing Exif rotation
b) Setting shortcuts for this is somehow difficult (as the KDE dialog for setting short cuts is a bit confusing)

So it look forward to see this working in an easy way (for example as explained in comment #16).

*** Bug 196383 has been marked as a duplicate of this bug. ***

This entry have been implemented by Marcel on current implementation from git/master (next 2.6.0)

You can now rotate RAW thumb/preview. In fact a rotation flag is fixed in thumbnails database. Raw file still untouched of course.

Gilles Caulier