Bug 328430 - Maximum thumbnail size of 256px is too small for big screens
Summary: Maximum thumbnail size of 256px is too small for big screens
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Thumbs-Image (show other bugs)
Version: 3.5.0
Platform: unspecified Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL: http://i.imgur.com/I910ZEn.png
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-04 21:09 UTC by Gregor Müllegger
Modified: 2014-05-22 21:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.1.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gregor Müllegger 2013-12-04 21:09:14 UTC
When I import shots from a trip I usually have a few hundred pictures that I quickly want to sort and filter by their quality. Therefore I tag them with the "accepted" (green flag) and "rejected" (red flag) etc.

At the moment I need to open the big preview image in digikam to actually be able to see some details of the image. That has the bad sideeffect that the thumbnailbar at the top doesn't show all the details that the thumbnails in the album preview do. Like filename, status (the green/red flags), tags and so on.

Currently the maximum thumbnail size is limited to 256px in the album preview, but I don't see any reason why it is set to this value. It would be nice to increase that value a bit more. I'm working on a 27" with a resolution of 2560x1440, which is not uncommon anymore these days. Having at most three thumbnails next to each other would be desired, therefore the maximum thumbnail size should be increased to at least ~800px.

Here is a screenshot of my workspace which should make clear that bigger thumbnails are more desirable: http://i.imgur.com/I910ZEn.png

Thanks for creating such an awesome photo manager!

Reproducible: Always
Comment 1 Christoph Feck 2013-12-04 22:36:24 UTC
Note that 800x800 is already 10 times as large as 256x256, which would make the thumbnail database really large. If larger previews get implemented, they probably should simply load the real file instead (which can still be scale-loaded fast, if they are in JPEG format).
Comment 2 Gregor Müllegger 2013-12-04 22:52:09 UTC
Yes I think it's a good idea to load the real image anyway after you go beyond a certain size. JPEGs are fast to load, and RAWs usually include full size JPG previews.
However I could imagine blowing the thumbnail size up to about 512x512 which would make the size fourth time bigger. It's quite a big improvement over the very tiny 256x256 but doesn't sacrifice space too much.

As an example my current collection is 245 GB in total, the thumbnail database is 1.4 GB. If that is multiplied by four it's roughly 6 GB, which is 2.5% of the collection's size. In my opinion that's a reasonable space overhead.
Comment 3 caulier.gilles 2013-12-04 23:06:35 UTC
Hi,

Originally, digiKam follow FreeDesktop specification (before to use a dedicated database to store         
thumbs), and maximum size was limited to 256x256. This specification is also used by all other program, as Dolphin or Gwenview.

http://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html

I understand the UHD screen size problem with thumbs. I fully agree that something must be done in this way.

512x512 sound like a good compromise. Don't forget that we use PGF wavelets compression format in DB to optimize space storage and quality.

Note that only digiKam can be improved in this way. Showfoto which use thumbnails for thumbbar do not use a DB, but old FreeDesktop standard.

Gilles Caulier
Comment 4 caulier.gilles 2013-12-04 23:08:01 UTC
Ah, I forget to precise that if 512x512 must be supported, this must be a option disabled in digiKam setup dialog by default.

Gilles Caulier
Comment 5 caulier.gilles 2013-12-04 23:23:44 UTC
Marcel,

Any technical objections to pass from 256 to 512 max thumbnails size for database storage ?

I already check in source code, and changes are not too many intrusive...

Gilles Caulier
Comment 6 Marcel Wiesweg 2013-12-05 17:43:21 UTC
Well yes, harddisks are growing, memory is cheaper, so why not.
We must be careful to check all places in our code where "256" is hardcoded. There are quite a few.
What should happen with all the thumbnails in the databases of our users that are stored as 256?
Comment 7 caulier.gilles 2013-12-05 17:56:38 UTC
Thanks Marcel,

Yes i find a lots of place where 256 is hard-coded... So i will take a care here...

If we provide an option to switch from 256 to 512, well we can force to all thumbnails to be recomputed with maintenance tool. This is already the case when we play with Setup/Metadata/Rotation/advanced options...

Gilles
Comment 8 Gregor Müllegger 2013-12-11 18:57:07 UTC
A suggestion to how old entries in the thumbnails DB could be treated:

Users might have set their thumbnail size to 200px with the current version of digikam. Once bigger thumbnails are allowed in a digikam release, the currently selected size stays at the user defined 200px but the slider allows for values up to the new maximum (let's say 512px).

Currently the DB is filled with thumbnails of the size 256px. As long as the user doesn't increase the thumbnail size above 256px, nothing should happen. If the user increases it to 257 or above, the thumbnails for the currently shown directory should be recalculated, but till the recalculation finished, the old thumbnails are shown but are upsized. So you can at least see what's in the picture, but get a pixalated bad thumbnail until the computation is complete.

That also happens when you have now the slider at 512px and enter another directory with smaller thumbnails. Once you have for 512px thumbnails but decrease the thumbnail size slider to below 256px, no recomputation will be made. The 512px version is shown, downsized.

Additionally recalculating the thumbnails via the maintainer dialog should produce thumbnails in the size of 512px and discard smaller ones.


I don't have any knowledge of the digikam code structure, so I don't know how reasonable the explained strategy is. See this just as an inspiration for a possible implementation :)
Comment 9 caulier.gilles 2014-05-22 12:58:36 UTC
I plan to patch digiKam for next 4.1.0 release to support max thumbnails size of 512x512. It's not yet complete, but it's basically work as expected :

https://www.flickr.com/photos/digikam/14242045372/sizes/o/

I would to make it configurable and let's 256x256 size by default to not bloat thumbs database with large thumbs if user don't use an high resolution screen (as WQHD of 4K monitors).

Gilles Caulier
Comment 10 caulier.gilles 2014-05-22 21:41:10 UTC
Git commit aaa82a1055ea58b8dbe56d496b063edaaa9a7f85 by Gilles Caulier.
Committed on 22/05/2014 at 21:37.
Pushed by cgilles into branch 'master'.

Add new option to support icon-view large thumb size (over 256x256 px)
If you use large screen resolution, as WQHD or 4K monitor, you can now use until 512x512 px size for thumbnails.
When this option is turned on/off from setings panel, user need to restart digiKam to take effect, and thumbnails
need to be rebuild over collection through MAntenance tool, to update digiKam thumbs database.
FIXED-IN : 4.1.0

M  +1    -0    CMakeLists.txt
M  +1    -1    digikam/items/imagedelegate.cpp
M  +3    -0    digikam/utils/albumsettings.cpp
M  +3    -3    digikam/views/digikamview.cpp
M  +1    -1    digikam/views/tableview_column_thumbnail.cpp
M  +2    -2    libs/threadimageio/loadingcache.cpp
M  +1    -1    libs/threadimageio/thumbnailcreator.cpp
M  +2    -1    libs/threadimageio/thumbnailcreator.h
M  +6    -6    libs/threadimageio/thumbnailloadthread.cpp
A  +102  -0    libs/threadimageio/thumbnailsize.cpp     [License: GPL (v2+)]
M  +33   -37   libs/threadimageio/thumbnailsize.h
M  +3    -3    libs/widgets/mainview/dzoombar.cpp
M  +2    -2    utilities/importui/items/importdelegate.cpp
M  +3    -3    utilities/importui/models/importthumbnailmodel.cpp
M  +3    -3    utilities/importui/views/importview.cpp
M  +12   -3    utilities/setup/setup.cpp
M  +1    -1    utilities/setup/setup.h
M  +50   -3    utilities/setup/setupalbumview.cpp
M  +7    -1    utilities/setup/setupalbumview.h

http://commits.kde.org/digikam/aaa82a1055ea58b8dbe56d496b063edaaa9a7f85