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:

1. 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.

2. 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 use exiftran 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.