Version: Revision: 603502 (using KDE Devel) Installed from: Compiled sources Compiler: gcc (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) OS: Linux I've seen quite a few bugreports (like 131603 or 127577) for thumbnails and rotation and not showing correctly, this is more of a suggestion to fix things manually sort of... Some of the thumbnails of raw images (CRW) are showing up rotated 180 deg. I'm not sure if it's the orientation of the camera or some other factor, but it's very odd. I'd like to be able to rotate the thumbnail to show up right. Strangely, opening the image in the editor gives me a right side up version of the image and also the whitebalance and gamma is immediately adjusted, I'm not sure if that's something I did or the default setting (could be more clear) Finally, isn't it strange to modify the raw image at all? I see it as the negative in a film camera, so you don't change that in any way. I wouldn't offer the rotate image option in the right-mouse-menu with raw images, but instead allow the thumbnail to be rotated. I'll attach a fragment of my album window to show the problem.
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