Bug 193967

Created attachment 33985 [details]
%s/Smooth/Fast/ Transformation

I was too fast. First replace is harmful -> it generates lower quality thumbs. Have to test it more - but second part is still valid!

SVN commit 972480 by cgilles:

optimize QImage scaled 2nd pass to use fast transform instead smooth transform. Quality still here.
BUG: 193967


 M  +7 -8      thumbnailcreator.cpp  
 M  +3 -0      thumbnailcreator_p.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=972480

For me thumbs have bad quality now, Gilles i guess yours are ok because they have been already created before?
What when removing .thumbnails folder?

I remember some blog entry on the QtLabs homepage where some way was introduced to have good AND fast scalings. Need to search for this...

Andi

Ah, here it is:
http://labs.trolltech.com/blogs/2009/01/26/creating-thumbnail-preview/

Also, this cheat scale seems to be even faster then FastTransformation, but looks like SmoothTransformation.

Andi,

Of course, i have tested to remove ./thumbnails (:=))) It still good quality without anti-aliasing if thumbs size is less than 256. At 256, smoothscale version is used (from cache).

What do you mean by bad quality exactly ? Can you take a screenshot ?

Gilles Caulier

Andi,

The question is : why i cannot see any signifiant differences here when size < 256 ?

Gilles

Created attachment 33988 [details]
FastTransformation - 137px thumbnail size

Created attachment 33989 [details]
256px thumbnail size

As you can see in the above screenshots, the outlines are very jaggy.

Andi - for me 256px thumbnail is smooth as previously. Smaller thumbs *are* jagged but not to such extent. Only in 80px I see something like on your screenshot and only on pictures with high contrast. What is your graphic card and drivers? (I have old Nvidia with legacy, proprietary OpenGL drivers)

Gilles - maybe some misunderstanding? My idea/patch was only simple replacement of Smooth with Fast, there is no second pass and writing of it is beyond my capabilities.

Personally this trade off - lower quality of thumbnails for faster loading of them is preferable - even welcomed with enthusiasm. Previously loading of whole screen of thumbs could take 4-5 seconds. Now filling the screen with thumbs take about 1 second. Judging from number of wishes for preloading of thumbs speed is important for users.

1 second? When generating the thumbnails? Then my system is crap, although I have a MacBookPro Core 2 Duo. It takes 8 seconds and more for one page (smallest thumbsize, approx 40 thumbs per page).
But if you mean the loading of the thumbs that are already cached / generated, this is not faster for me.
The approach in the above Qt Labs blog entry should be even faster then FastTransform AND look better, so maybe we should try this method?

Andi

Below I will attach copy'n'paste patch with "cheat" method from Ariya.

1) his method doesn't care about aspect ratio so you will see squares but as quick tool for tests it is enough
2) it is slightly slower than fast transformation - he probably tested it on big images where it is easier to gain performance, we are going only for scaling 256px downwards to 80px; on my screen smallest thumbs (55 pieces) take  3 seconds to fill the screen; It would be interesting to see what this method gives for generation of real thumbs; all times are for already generated thumbs and I see difference between loading of pregenerated thumbs before and now (Gilles patch doesn't touch generation of thumbs at all)
3) my computer: Sempron 2200, 756MB RAM (233 MHz), GeForce2 MX 400; Qt4.5.1, KDE4.3svn
4) bit tricky legal issues: file of origin where cheatScale is coming from is under GPL2 or 3, while thumbnailcreator.cpp is GPL2+
5) what is taking so much time is loading of thumbnails in sequence; would it be possible to load them simultaneously (thread per thumb or at least few threads per whole screen)?

Created attachment 33995 [details]
hack'n'slash patch for 'cheatscale'

We should be careful, if we use FastTransformation and users notice that thumbnails look "bad" then it makes a really bad impression on the average user.
On my system, thumbnail loading is not significantly bothering me at all. Creating takes its time, but loading is fast enough. I usually use thumbnail size 160 and I never "wait" for thumbnails to appear once they are created.

Yes, here too. I don't see a difference once the thumbs are generated. The creation is slow, this could be faster (maybe with this cheat method, so it would also look nice?)

Andi

#16 : I'm agree with Marcel. We must take a care to not make a bad impression
about thumbs.

#14 : agree with Mik, but speed-up improvements can be see on Single CPU
computer. On Double core, nothing (tested on 8 differents computers)

What do you think about this way :

1/ Always compute cache with SmoothScale to 256x256.
2/ In second pass,

- If size is 256, do nothing.
- If 256 > size >= 128 : use cheatscale
- If size < 128 : use FastScale (we cannot see details indeep here).

Or perhaps alwyas use cheatscale if size < 256. In all case, no need to to
touch thumb if size = 256.

Gilles

BTW - very, very interesting link about generation of thumbnails:

http://www.4p8.com/eric.brasseur/gamma.html

Andi,

Another way to try is to use DImg instead QImage with Fast Scale algorithm taken from imlib2...

Gilles

Gilles

1) as Andi wrote it would be good to test how generation of thumbs with cheatScale is going
2) I think I understand misunderstanding. For you second pass is when thumbnails were generated and only loaded from disk; for me second pass means that when loading thumbs they are loaded in two steps - first with FastTransformation, second time, after 2-3 seconds of inactivity in Album GUI, with SmoothTransformation; in your terminology it would 2.5 or 3 pass.

About sizes:
size == 256 do nothing - as far as I understand this works now
size < 128 - in this area side effects of FastTransformation are really visible so here users will be hit hard in quality

When 3 people told me that they see no difference I recompiled digiKam for each of three variants (Smooth, Fast, cheat) to test again. Well, I see difference between Smooth and Fast - maybe not so dramatic as I perceived yesterday - but there is. May it be not worth to sacrifice quality? For me trade-off is worth but for most of users of this solution it is not.

So, I propose to revert this whole thing but still investigate use of cheatScale for .thumbnails generation.

> So, I propose to revert this whole thing 

I strongly agree. For me all thumbnails look pixellated with the current solution.

SVN commit 973246 by cgilles:

revert 
CCBUGS: 193967


 M  +1 -2      thumbnailcreator.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=973246

SVN commit 973247 by cgilles:

revert 
CCBUGS: 193967


 M  +1 -2      digikamthumbnail.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=973247

SVN commit 973970 by cgilles:

try cheat scale. It's really faster now ???
CCBUGS: 193967


 M  +8 -2      thumbnailcreator.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=973970

Let's me see if thumbnails creation is a little bit faster for you now...

I still convinced that a lots of time is used to save png file to .thumbnails cache. 

Just do a simple test :

1/ start digiKam 
2/ go to a console and remove ~./thumbnails (let's open digiKam session)
3/ now navigate into albums : it's really fast

Why ? Because ~./thumbnails dir disappear and digiKam cannot save in cache. There is no more access disk.

Gilles

Created attachment 34073 [details]
Thumbnails settings panel from Gwenview for KDE3

Look like Gwenview has an option to disable thumbs cache synchronization. This is why it can be very fast to generate thumbnails on icon view.

@26, Gilles - this trick doesn't work for me, digiKam here creates .thumbnails dir and writes there :)
@25, Gilles - yes it is faster - one thing I missed previously, in this place digiKam creates thumbs only for non-jpg files so I see difference for TIFFs. JPEGs are handled by local copy of jpegutils.

@27, Gilles - made simple tests by commenting out code responsible for writing of qimage to disk. There are speed gains when viewing images for first time but when going to the same folder second time it is approximately two times slower than with support of .thumbnails cache. For image viewer like Gwenview it is acceptable but not for full blown image organizer like digiKam.

Could be done for Showview.