#24 Speed up thumbnail generation for RAW files (incl. howto)


Currently, mapivi uses ufraw to generate thumbnails for RAW files. However, the procedure is very CPU expensive and thus slow. From the command used

sh -c "ufraw-batch" --silent --wb=camera --black-point=auto --exposure=auto --create-id=also --out-type=png --out-depth=16 "--output=/tmp/magick-XXCyuyPe.png" "/tmp/magick-XXUdycXg"

it seems that mapivi is calling image magick which is calling ufraw as delegate. From the delecation it becomes clear that the slowness of this procedure results primarily from the fact that a full raw development is done here (note: even in 16bit colour depth!) then the image is scaled down to some 160x120pixels and reduced to 8bit jpg for the thumbnail usage. Thus, a very high quality intermediate step is used without any need or reuse.

Thus it seems possible to speed up thumbnail generation considerably by using cheaper procedures. Instead of developing the RAW one could just extract the embedded preview images already available and just scale them down. To extract embedded JPG preview images one might use

$ ufraw-batch --embedded-image input.nef --out-type=jpg --output=.thumbs/input.nef

This pure extraction is done in nearly no time, only scaling is left to consume CPU cycles. Probably, this call could be included in extractThumb in case no Exif-thumbnail is found.

Given the procedure currently used by mapivi one might on the other end consider it a feature: if the above mentioned expensive procedure is used one should probably just store the fully developed jpg file along with the RAW files and thus incorporate them in the general jpg-centric workflow of mapivi. One would then end up with the usual JPG+RAW type of images that work flawlessly with mapivi. It only seems advisable to tag those automatic files then with a special keyword for easy reference so the user can easily redevelop them in case necessary.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks