. Reproducible: Always Steps to Reproduce: 1. Import > Card Readers > download photos from my SD card to my HD. I have a Pentax K10D camera fwiw. 2. Go to the folder with the downloaded images, click on the first, F3 to preview it, and keep advancing to the next image. 3. I shoot panoramas and I use 5-step bracketing, so I end up with typically 8 angles: 6 around, nadir and zenith, and 5 bracketed shots per angle, for a total of 40 shots. These shots are identical in every way. The bug is that while viewing the previews, some shots look as if I zoomed in a bit. This is impossible - it's not a zoom lens, and my tripod is rock solid. Looking at the actual raw files in RawTherapee confirms that they are identical other than the actual exposure. Looking at the embedded JPEG previews in Geeqie also confirms that the preview matches the raw file. So the bug is in digiKam, which sometimes for some reason decides to crop the thumbnail by a few pixel rows and columns around the periphery, which makes it look as if I screwed up. This means that I cannot use digiKam to sort my photos because the preview lies - I might end up deleting photos thinking that I screwed up, when in fact the photos were perfect. For this reason, I am marking this bug as "major", because digiKam fails at its most basic purpose when I cannot even reliably preview my raw photos, and therefore is unusable. I urge you to look into this before releasing 4.8.0. I see no point making another release when something so basic is unreliable, and viewing previews MUST be absolutely reliable.
I copied the same photo several times into a new test folder. I rotated one of them 90 degrees clockwise. http://i.imgur.com/62hVOjE.png Viewing the next photo after the rotated one triggered this bug, the photo's preview was the wrong size and strangely enough the exposure was also different. The next photo after this one was correct. I alt+tabbed back here to write then, then I alt+tabbed back to digiKam, rotated another photo, and now neither of them show the bug... I triggered it again, this time on a pair of photos (remember, this is the same file, copied many times!) rotated left. http://i.imgur.com/hngMXZJ.jpg http://i.imgur.com/nPJ6MWa.jpg One is the JPEG preview, the other is the half-size raw preview. Why? We've been discussing this in some other issue for over a year now, that these automatic heuristics are a _VERY BAD IDEA_. I'm quite tired of banging my head against the wall release after release, where each patch breaks something more. Does anyone test these patches before committing them, is there any quality control in digiKam?
"I'm quite tired of banging my head against the wall release after release, where each patch breaks something more. Does anyone test these patches before committing them, is there any quality control in digiKam?" There is no QA in digiKam project. In fact we work in blind mode without any management, direction, goal, etc... In fact it's a pouring project ! I'm quite tired about a complain. Pay a proprietary application and complain outside open source world ! Gilles Caulier
I can not reproduce the issue with the zoomed preview. In what kind of a preview, only fast preview or even RAW half size preview? Always with the same images? If yes -> can you upload test images? Maik
Maik: http://rawtherapee.com/shared/test_images/amsterdam.pef Settings > Album View > Preview Options > Raw images: Automatic Rotating an image should not be a factor in whether the embedded JPEG preview or a fast-demosaiced raw preview is used. You may wonder why would I rotate some images when shooting a panorama. The reason is that when my camera is rotated 45° (or with a pitch +90° or -90°) then the orientation sensor goes a bit crazy and some images (even those belonging to one bracketing series) end up with their metadata "orientation" tag set to portrait and others landscape, even though the camera and tripod were perfectly still and I used a cable release. When I rotate them all to be portrait, I expect them to look identical, because they are identical.
Created attachment 91112 [details] autopreview.patch In the automatic RAW preview I could reproduce the issue. When loading the JPG preview was canceled (fast move to next images) in the cache, the RAW half size image was always loaded.
Git commit 1e1b50b206878e509b0c5305b4ca8bbd19a96f8e by Gilles Caulier. Committed on 17/02/2015 at 09:11. Pushed by cgilles into branch 'master'. apply patch #91112 from Maik Qualmann to cancel raw preview loading if necessary when image preview switch from one item to another one. FIXED-IN: 4.8.0 M +2 -1 NEWS M +5 -0 libs/threadimageio/previewtask.cpp http://commits.kde.org/digikam/1e1b50b206878e509b0c5305b4ca8bbd19a96f8e
Git commit b7ee9bd9f9d9fe474df5f218f704e243e59bc74e by Gilles Caulier. Committed on 17/02/2015 at 09:19. Pushed by cgilles into branch 'frameworks'. backport commit #1e1b50b206878e509b0c5305b4ca8bbd19a96f8e from git/master to frameworks branch M +31 -4 libs/threadimageio/previewtask.cpp M +6 -1 libs/threadimageio/previewtask.h http://commits.kde.org/digikam/b7ee9bd9f9d9fe474df5f218f704e243e59bc74e