News

Improvements on video support13 May 2012

Jesper was on a vacation and by tradition this means some news for KPhotoAlbum as well. This time he was hacking together some improvements on video support - and a lot of things under the hood. On visible side it is now possible to select the frame to be used as video thumbnail and while hovering over a thumbnail a few frames from the video are cycled over to give better idea what the video is about. Less visible improvements include e.g. new background tasks manager. It sure is great to see Jesper busy on improving KPhotoAlbum once in a while.

— Miika

KPhotoAlbum 4.2 released31 Mar 2012

We are happy to announce a new release of KPhotoAlbum. The major changes including stability and speed improvements were described when announcing the release candidate 2. After that only a few minor changes were made.

You can get the KPhotoAlbum 4.2 from KDE mirrors.

— Miika

Release Candidate 2 for KPhotoAlbum is available09 Mar 2012

Release candidate 2 of our next release is available on KDE FTP site.

Changes since the release of 4.1.1 include the following:

  • Rewrite of ThumbnailView with speed improvements, pre-loading and background thumbnail generation.
  • ToolTip on ThumbnailView is activated only if mouse is not moving.
  • Updated documentation.
  • Copy-paste of tags from one image to the next one.
  • RAW workflow improvements on speed and functionality. Use embedded thumbnail if available in decent size, open the RAW file in RAW editor instead of the developed JPEG, search for only RAW files.
  • Rating images with number keys 0-5.
  • Annotation dialog and search improvements.
  • HTML export improvements.
  • Option to skip symbolic links when detecting new files.
  • Multi core CPU improvements.
  • Plenty of crashes fixed.
  • Usability improvements.

Working on new release of KPhotoAlbum20 Feb 2012

We are working on a new release. New features are frozen and the current GIT master should have all the features to be expected on the release. Some more bug fixes should be done before the release. We are planning on providing a release candidate soonish before the final release, but there is no date set for that.

There has also been a major change in the forces behind KPhotoAlbum. Jesper has decided to step back and has left a huge gap for other people to fill. We want to thank Jesper for his great work in producing the best photo cataloguing software known to exist!

KPhotoAlbum has moved to git28 May 2011

KPhotoAlbum's source code is now stored in KDE's git repository instead of SVN. See The instructions on how to check KPhotoAlbum out from git

Summer vacation means much faster thumbnail viewer.16 Aug 2010

I've just returned from one week of vacation on Zakynthos in Greece, and the result is the same as every year of summer vacation - a lot of time to spent on KPhotoAlbum :-)

This year I rewrote the thumbnail viewer from the old Q3IconView to Qt4's QListView, and while I was at it (and yes that was really my starting point), I optimized the loading of thumbnails quite a bit. We are talking about orders of magnitude here!

The technical details - in case you care

Just prior to my vacation I experienced with storing thumbnails in one large file, which is much faster to load than storing each thumbail in a file of their own. See the details in my blog

This is what I do now, but that really only contribute to a minor part of the speed up, it turned out that thumbnails was scaled when loaded from the cache - at the time that seemed like a good idea, but the result was that each thumbnail costed an extra 10 msec - which amounts to a whole second for 100 thumbnails. Now the images in the cache has the actual size needed. This means that it is flushed each time you resize the thumbnail - so stop doing that a lot :-)

Another slowdown was the drawing of the 3D effect around each thumbnail. By changing that from drawing 5 rectangles to drawing 5 filled rectangles, I got a huge speedup :-)

What are the catch?

So is this all great, no catch?, well there is a few minor ones.

  • We are storing the thumbnails in our own format now, so other application wont be able to reused them - anyway, that has been so for a few years already, so no big deal.
  • Thumbnails needs to be recreated when thumbnail size is changed. This was the price we had to pay for this, as the alternative, which we used before, was to store the images in say 256x256, and then scale them down, but that was exactly what costed a lot.
  • When you resize the thumbnails, new thumbnails are generated for all the videos too. As the thumbnail for the videos are a random screenshot from the video, this means that it will change each time, which might make it harder to recognize them.
  • The old selection model of the thumbnail viewer has been replaced with QListView's version. This means you do rectangle selections with the mouse. I might rework that to use our own selection method again later on, if there is a public demand for it.
  • I'm sure I've introduced a lot of new bugs :-)

What are the advantages?

  • Much much faster - we are talking about smoooth scrolling now, something like going over say 5-10 pages of thumbnails per second, where the old implementation took perhaps 1-2 second per page.
  • The code has been rewritten to use Qt 4's QListView, which means a lot of code had been cleaned up - to the end user this means fewer lines for us developers to add bugs to :-)