[digikam] [Bug 328430] New: Maximum thumbnail size of 256px is too small for big screens

[Gregor Müllegger]

https://bugs.kde.org/show_bug.cgi?id=328430

            Bug ID: 328430
           Summary: Maximum thumbnail size of 256px is too small for big
                    screens
    Classification: Unclassified
           Product: digikam
           Version: unspecified
          Platform: unspecified
               URL: http://i.imgur.com/I910ZEn.png
                OS: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: Preview
          Assignee: [hidden email]
          Reporter: [hidden email]

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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|Preview                     |Thumbnails
            Version|unspecified                 |3.5.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Christoph Feck]

https://bugs.kde.org/show_bug.cgi?id=328430

Christoph Feck <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Christoph Feck <[hidden email]> ---
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).

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gregor Müllegger]

https://bugs.kde.org/show_bug.cgi?id=328430

--- Comment #2 from Gregor Müllegger <[hidden email]> ---
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.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

--- Comment #3 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

--- Comment #4 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #5 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=328430

--- Comment #6 from Marcel Wiesweg <[hidden email]> ---
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?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

--- Comment #7 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gregor Müllegger]

https://bugs.kde.org/show_bug.cgi?id=328430

--- Comment #8 from Gregor Müllegger <[hidden email]> ---
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 :)

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

--- Comment #9 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
      Latest Commit|                            |http://commits.kde.org/digi
                   |                            |kam/aaa82a1055ea58b8dbe56d4
                   |                            |96b063edaaa9a7f85

--- Comment #10 from Gilles Caulier <[hidden email]> ---
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

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=328430

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Version Fixed In|                            |4.1.0

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel