Version: 0.9.1 (using KDE KDE 3.5.5) Installed from: SuSE RPMs OS: Linux I have several png-pictures in a folder/album. I click on one to preview it. Then I go back to the collection and rotate the image using CTRL+9. The picture is still shown with the old oriantation in the collection, even clicking on it does show the old orientation. Viewing it in konqueror however does show it with the correct orientation. Expected behaviour: Update any (pre-)view after rotating the picture.
With the version from current SVN I cannot confirm this problem, everything works all right. (shortcut is now Ctrl+Shift+Left, but I assume Ctrl+9 is the old one for the JPEG lossless plugin). I dont know anymore what was already in 0.9.1 - maybe this problem has been fixed since then?
This problem is not reproductible here. images are rotated and thumbnails updated... Gilles Caulier
> ------- This problem is not reproductible here. images are rotated and > thumbnails updated... Are you using jpg-images? It does work with them for me as well, but not with the jpegs that were converted to png while downloading.
I have a big collection of pictures, JPEG, PNG TIFF, etc, and all work fine... Gilles
The rotation function from digiKam main interface is provided by a kipi-plugins. Witch version of kipi-plugins you use? Are you compiled yourself kipi-plugins ? If yes, witch compilation options have you used ? Gilles Caulier
> ------- The rotation function from digiKam main interface is provided by a > kipi-plugins. Witch version of kipi-plugins you use? The rotation works fine, if I view the picture in konqueror or digikam's image-editor it is displayed correctly. I enabled the rotate according to EXIF information (my camera does not support it) and it re-created all thumbnails, yet it still displays the original rotation. > Are you compiled yourself kipi-plugins ? If yes, witch compilation options > have you used ? SuSE RPM 0.1.5
>>>>SuSE RPM 0.1.5 this is libkipi package release, not kipi-plugins. current kipi-plugins developement version from svn is 0.1.4-beta1 Gilles
0.1.3 from packman.
S. Burmeister, Ok, now i can reproduce the problem and i have a patch against kipi-plugins svn (KDE3 branches). I will apply it and i would to have a fresh report from you... Gilles
SVN commit 716889 by cgilles: kipi-plugins from KDE3 branch : JPEGLossLess plugin : new method to update metadata from non-JPEG pictures processed with ImageMagick (TIFF/PNG for Ex.) Updating include IPTC preview image used to render thumbnails in digiKam. CCBUGS: 144388 M +5 -0 convert2grayscale.cpp M +5 -0 imageflip.cpp M +11 -0 imagerotate.cpp M +1 -0 imagerotate.h M +1 -1 jpegtransform.cpp M +121 -0 utils.cpp M +23 -2 utils.h WebSVN link: http://websvn.kde.org/?view=rev&revision=716889
Angelo, Arnd, The same problem exists with BatchProcessImage plugins witch use ImageMagick... Gilles
Angelo, Arnd, Wrong alert. BatchProcessImages only work on a copy of picture, not on original. Gilles
SVN commit 716981 by cgilles: backport commits #716889 from KDE3 branch BUG: 144388 M +8 -0 convert2grayscale.cpp M +9 -0 imageflip.cpp M +8 -0 imagerotate.cpp M +1 -1 jpegtransform.cpp M +123 -0 utils.cpp M +28 -5 utils.h WebSVN link: http://websvn.kde.org/?view=rev&revision=716981
Gilles I've never seen BatchProcessImage code....