After upgrading to Ubuntu 18.04 I realized that both gnome-raw-thumbnailer and ufraw-batch are broken. There is even an open bug which may be fixed someday…
I have tried liblensfun and ufraw-batch both from ubuntu repo and Pascal’s repo. Both failed.
Ufraw-batch throws segfault at liblensfun (even with option --lensfun=none)
Gnome-raw-thumbnailer ends with (strace):
dup2(1, 3) = 3
dup2(2, 3) = 3
close(1) = 0
close(2) = 0
openat(AT_FDCWD, NULL, O_RDONLY) = -1 EFAULT (Bad address)
dup(2) = -1 EBADF (Bad file descriptor)
write(2, “Bad address\n”, 12) = -1 EBADF (Bad file descriptor)
exit_group(-1) = ?
+++ exited with 255 +++
Any solution to that? Any other thumbnailers for nautilus?
Rapid Photo Downloader will create thumbnails for files it downloads, but of course that’s absolutely no help when you already have the files on your system.
As an aside, pretty much every contemporary camera I’m aware of generates full size jpeg previews and embeds them in the raw file. They do this so they can display high resolution images on the back of the camera LCD when you zoom in.
So any program these days that tries to generate 256 pixel previews from the raw data on anything other than raws produced by old cameras is grossly inefficient. It’s much, much faster to extract the full size jpeg and downsize it. If there is no full size preview, then calling on libraw is the best solution. I suspect libraw is much more widely used and better supported than libopenraw.
It would be good if someone forked my thumbnailing code in Rapid Photo Downloader and created a new raw thumbnailer. For someone with the requisite Python skills it should not be too difficult. I don’t recommend it to someone new to Python, because the code is multi-core / parallel by design, for high performance.
An alternative would be to adapt Canoncial’s thumbnailing code they developed for their phones. My impression is that they made a strong effort to make it as fast and efficient as possible.
I have no idea what the KDE folks do. Maybe they have something that can be adapted too.
I looked at it briefly. You’re using Qt framework for threads. I guess it’s very fast.
Just for now I have downloaded liblensfun src package and recompiled it with debug symbols. With debug liblensfun ufraw-batch works (too many times I have seen this…).
Threading in Python is within the same process, so Python threading doesn’t improve performance per se. The threads are just to facilitate communication between processes, which actually occurs using something called zeromq. In other words, the threads are just little helpers, playing a very minor role.