Version: (using KDE 4.3.4) OS: Linux Installed from: openSUSE RPMs Hi After upgrading digiKam from 0.10 to 1.0.0 most thumbnails seems to be quite blury. Especially thumbnails for jpeg images. RAW, Canon, seems not to be effected. I have tried with regeneration of all thumbnails, but without any luck. I'm running openSUSE 11.2 with digiKam from KDE:Backports. I had a little discussion about this on the digikam-users mailing list. A suggestion was to contact libpgf also. I haven't done that yet, but I will. /Anders
Can you please provide a screenshot and, if possible, a screenshot of how this was before the update?
I will try to have a after/before screenshot. I haven't 0.10 installed anymore.
Where were the thumbnails stored in 0.10?
0.10 used the .thumbnails folder in your home directory.
Created attachment 40413 [details] Thumbnail1, digiKam 0.10 The first thumbnail from digiKam 0.10.
Created attachment 40414 [details] Thumbnail1, digiKam 1.0.0 The first thumbnail, for digiKam 1.0.0.
This problem have been already discuted to digikam-user@kde.org mailing list recently. With 1.0 release, thumbnails are stored in a dedicated database using PGF format (wavelets compression) to reduce space on your hard drive. With digiKam 0.10, PNG format is used. It sound like the PGF compression ratio used in digiKam 1.0 is a little bit high. Perhaps we can just reduce this value by one point or provide a simple settings in setup dialog. Code relevant is there : http://lxr.kde.org/source/extragear/graphics/digikam/libs/threadimageio/thumbnailcreator.cpp#501 '4' is the compression level. A value up to to 4 is very destructive. A lesser value has better quality, but size data is up. A zero value is a lossless compression as PNG. This can be also an issue to libpgf, as an improvement to do to algorithm to preserve quality of image in all case. I know that pgf team is focused to provide a fast algorithm against quality when compression level is up Gilles Caulier
Hi Gilles It was me who opened that discussion :) Can't we have the user decide what choose the compression level instead of a fixed value in the code? Another thing is that the thumbnails are better for raw images or png. How can that be. I have uploaded two thumbnails of the same image. The thumbnail from digiKam 1.0.0 is a screenshot, while for digiKam 0.10 I took it from the .thumbnails/large folder. /Anders
Can you also give us the original image?
(In reply to comment #9) > Can you also give us the original image? I can do that, but I have to wait until I get home. /Anders
I wasn't allowed to upload the image. It's to big. Any suggestions where I can store it? /Anders
Give an url to web space or send image by mail to Marcel Gilles Caulier
Here's a link to the image: http://s746.photobucket.com/albums/xx106/falolaf/?action=view¤t=gotland_2008-04-27_161621.jpg /Anders
(In reply to comment #13) > Here's a link to the image: > http://s746.photobucket.com/albums/xx106/falolaf/?action=view¤t=gotland_2008-04-27_161621.jpg > > /Anders That was a bad choice, the image was resized. I will send it by mail instead. /Anders
Created attachment 40569 [details] Result of thumb extraction and scaling This image is extracted from the thumbnail generation process and directly stored as PNG, before PGF compression. Compared to the 1.0.0 thumbnail which you provide I see some minor blurring on the white wall on the left and in the white grid in the background, but the major artifacts and the handrail are already present before libpgf compression
Created attachment 40570 [details] Result of thumb extraction and full smooth scaling The is also extracted from thumbnail generation process before PGF compression. This time, I disabled the "cheat scaling" and only used smooth scaling. From my impression, this is identical to the 0.10 thumbnail and better than the 1.0 version. This clearly shows that libpgf is not the problem here but the introduction "cheat scaling" (http://labs.trolltech.com/blogs/2009/01/26/creating-thumbnail-preview)
Marcel, Yes, it's clear that libpgf is not the problem here. Great to see... Gilles Caulier
Can this explain that thumbnails from RAW images seems to be unaffected? /Anders
It may be that RAW thumbnails are generated from a preview which is already smaller, or that for some other reason the scanning optimization actually works well for these cases.
I'm glad the source of this problem seems already found! If given the choice (like in gqview or geeqie) I always opt for high quality resizing of thumbnail pictures - even though I'm already on a "slow" machine (1 GHz). Maybe digiKam could also offer an option, or just change to a higher quality default re-size algorithm.
My suggestion would be to disable the cheat scaling for now and use good old smooth scaling? Gilles?
yes Marcel, fine for me... Gilles
SVN commit 1089637 by mwiesweg: Disable cheat scaling for thumbnails because of demonstrated quality regressions. BUG: 224999 M +2 -1 NEWS M +3 -0 libs/threadimageio/thumbnailcreator.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1089637
What disappointment! I had been looking forward to digiKam 1.2 because of this fix, but now my thumbnails seem even blurrier than before. I'll attach a picture with a comparison between digiKam 0.9, digiKam 1.0, and digiKam 1.2. Could it be that current digiKam only generates very small thumbnails and upscales them to a width of 256 pixels, if a user wants to see large thumbnail pictures?
Created attachment 42397 [details] Screenshots of three different digiKam versions.
Not reproducible there. Please regenerate all thumbnails for your collection using right option in Tool menu entry. Gilles Caulier
Hm, maybe I made a mistake somewhere, sorry! I tried digiKam 1.2 from Kaelo's PPA on my notebook, and thumbnails there look good. I'm currently recompiling digiKam 1.2 on my PPC computer, where I took the digiKam 1.2 screenshot. I'll write another comment, if there's still a problem on this computer (the old iMac).
After a lot of testing I'm still not sure where exactly the problem comes from, but it seems like there are both PPC specific as well as Ubuntu (or KDE 4.4) specific causes involved. I remember the thumbnails' new PGF format had issues with PPC hardware (big-endian) before, as was discovered in bug #210580. My findings (from just looking at the surface): - digiKam 1.2 on Ubuntu 10.04/ AMD64 (KDE 4.4.2) works very well. I tried both the PPA version and a package compiled from the sources on my system. Thumbnails look sharp, no matter whether they are displayed at 256 pixels or slightly smaller. - digiKam 1.2 on Ubuntu 10.04/ PPC (software versions should be identical to the AMD64 version) automatically creates very blurry thumbnails, as can be seen in my attachment from yesterday. But thumbnails look good when I set the slide to 256 pixels and regenerate the thumbnails using the entry from the "extras" menu! Still the thumbnails look blurry again when I reduce their size by just a few pixels, or when I restart digiKam. After a restart, they remain blurry even in 256 pixel size. - digiKam 1.2 on Debian/ PPC (sid, with KDE 4.3.4) behaves differently again. The thumbnails it generates are sharp, as long as they are displayed in 256 pixels width. If I slightly reduce their size, they look very blurry again. Thumbnails generated under Debian can always be restored to look sharp by changing their size to 256 - but thumbnails generated under Ubuntu always remain blurry (also under Debian, where I used the same home account with just a few pictures). I'd like to see what is really stored in the "thumbnails-digikam.db", but I don't know how to do that. My attempt with the "sqlite" command failed. Should I open a new bug report for this issue? I could call it "Thumbnails blurry on PPC (big-endian) platform".
You need the "sqlite3" tool. Type ".schema" to get the schema. The thumbnails are stored in PGF format as BLOB. In the db thumbnails are stored as 256px. That means at initial (slow) creation, the full image is loaded and then scaled to 256. The original bug here affected this step. When loading from the db (fast), the thumbnail is scaled to the desired size and then converted to pixmap.
Marcel, thank you for the hint with sqlite3, and for the explanation of the way digiKam handles its thumbnails. Indeed I can open "thumbnails-digikam.db" with sqlite3, but I don't know how to extract a thumbnail from it. Anyway that seems not very helpful to me know - what would it show, if the thumbnail was already saved blurry under Ubuntu? DigiKam 1.2 under Debian seems to save good thumbnails anyway, but still renders them in a blurry way as soon as I change their size. So I opened a new bug - #233094 - for this new problem. I currently don't have enough time to learn more C programming, examine how digiKam works internally, and start searching for the error myself, but I'm willing to provide more information, or test patches.