Make PCManFM display thumbnails correctly
PCManFM is a very good file manager. However, when using PCManFM, a problem has troubled me for a long time: When you rotate a JPEG image taken from mobile device, then save it, PCManFM still displays the old thumbnail (before rotate). Therefore, there is a discrepancy between what you see (in PCManFM) and what you get (in image viewer).
The problem is like a haunting ghost: It persists when you rename the file, when
you copy the file, even when you delete the whole thumbnail dirs
(~/.thumbnails
and ~/.cache/thumbnails
).
Finally, it turns out the problem is really a ghost: Exif. A Exif-formatted
JPEG image embeds a thumbnail in itself. PCManFM will use this embedded
thumbnail when compiled with USE_EXIF
(evidence). This saves
PCManFM from re-thumbnailing. However, the image editor you use to rotate the
image may not handle the thumbnail properly. So the image is rotated, but the
thumbnail isn’t. This is how the discrepancy comes to be.
You can use either Exiv2 or exiftool to detect whether there’s a thumbnail in the JPEG image:
exiv2 a.jpg | grep -i thumbnail
exiftool -ThumbnailImage a.jpg
If so, you can extract it to see if it matches the image itself. This will
output thumbnail to a-thumb.jpg
:
exiv2 -et a.jpg
exiftool -b -ThumbnailImage a.jpg > a-thumb.jpg
Finally, you can delete the thumbnail in the JPEG image if you don’t want it:
exiv2 -dt a.jpg
exiftool -ThumbnailImage= a.jpg
A quick solution
So there is a very simple solution: Strip Exif thumbnail from the JPEG image. Now open PCManFM again. The displayed thumbnail should update when you rotate the image. I checked the source code of PCManFM and LibFM to confirm the modification time of the cached image thumbnail will be compared against that of the image itself.
Personally, I feel this solution is good enough. It also comes with an additional benefit: The Exif thumbnail can take about 1% space of the image. Stripping it will not only fix the thumbnail display problem, but also save us some disk space. For example, if you have 1024GB of photos, then 1% saving will give you 10.24GB. However, if you really need to keep the thumbnail and want it to display properly, then you’d better look for image editors that can handle the Exif thumbnail correctly.
A better solution
The quick solution above falls short when you have large image files. Because Exif thumbnails are stripped, PCManFM has to re-generate them for display. The re-generation can be quite slow for large folders with many large image files. In this case, we may want to keep Exif thumbnails.
So now, our job is to make sure, when the JPEG image is updated, its Exif thumbnail is also updated. Many image editors fall short of this. But there’s a tool that does this great: exiftran, which is part of the package fbida.
We suggest you download fbida-2.13, because fbida-2.14, for some reason,
gives me a segmentation fault. Arch Linux users can do asp checkout fbido
and
then switch to the proper commit.
The compilation and installation are pretty straightforward and so omitted.
Use exiftran
Now you should have the binary exiftran
. This tool can do 2 great things:
-
It can do lossless rotations while caring about the Exif data. Specifically, it also rotates the Exif thumbnail. Plus, it can process multiple images at once.
If we use
exiftran
to rotate our JPEG images, then thumbnails will also be rotated and everything is good. No further problems.The rotation command is pretty simple:
exiftran -i -9 a.jpg
The rotated thumbnail has the same size as before.
-
It can re-generate the Exif thumbnail.
Even though we can use
exiftran
to rotate images, it doesn’t come with a GUI. We may still want to rotate images while browsing them with a GUI image viewer. In this case, we can useexiftran
to fix the Exif thumbnail after rotation is done.To re-generate the Exif thumbnail:
exiftran -i -g a.jpg
The re-generated thumbnail size is not configurable, but looks OK in most cases.