Not a bug

JPEG EXIF Rotation

olivier 5 years ago updated by Vlad R 2 years ago 12

Hi, first of all thank you for this great software!

I noticed that the way EXIF rotations are handled is not perfect.

I created a gallery with the files from https://github.com/recurser/exif-orientation-examples.

Regarding the thumbnails (tested in Firefox and Chromium):

- on my installation (2017.09.25), the number 1,3,6,8 are correctly rotated

- on demo.filerun.co (2017.09.25), they are all correctly rotated

However, when I open them for a preview, only the number 1 (without rotation) is correctly displayed (on demo and on my installation).

I digged further, and I think that demo.filerun.co correctly rotates the previews because it uses the ImageMagick "convert" binary.

See https://stackoverflow.com/questions/20600800/js-client-side-exif-orientation-rotate-and-mirror-jpeg-images for possible solutions.


Not a bug

In the meantime, all modern browsers have corrected this behavior and images, regardless of how they are loaded, they are displayed with the correct Exif orientation.

Under review

ImageMagick/GraphicsMagick is almost a requirement with FileRun. It used to be fine, in the old days, to use PHP's own image manipulation capability to generate resized previews of the image files. However, in 2017, most photography files are getting really large, and PHP's performance in comparison with a dedicated app such as IM/GM is ridiculously poor. We keep it for convenience, even though we know there are limitations, more like a workaround before the admin enables IM/GM.
We'll still take it into consideration and if there is more interest shown, we'll include the orientation correction when not using IM/GM. But my hopes are not very high.

I totally understand your point (I am now using ImageMagick on my installation :-).

With ImageMagick activated, all the thumbnails are fine.

However there are still some issues:

- on a shared folder gallery: the fullscreen view is not rotated at all (expect on firefox when I manually add `image-orientation: from-image`)

- on my own gallery, the preview is not rotated

- on my own gallery, the zoomed view is not rotated

This answer seems like a nice trick: https://stackoverflow.com/a/46013100/3207406 (PHP + CSS cooperation)

When the size of the preview is not much smaller than the actual file, FileRun serves the actual file, without doing a resize, as it's much quicker to transfer it to the browser than processing the file on the server side. Unfortunately browsers don't yet support auto-orientation of images loaded inside pages (except Firefox with its "image-orientation: from-image").

The linked solution is elegant, but it is not that easy to implement inside FileRun, as FileRun doesn't make server requests other than for the image itself, when the user double-clicks it, and that would mean to have FileRun extract the EXIF information on all image files, before listing a folder contents, an action which would take too much server resources and will make large folders take long to list.

If the other browsers implement "image-orientation: from-image" we'll make FileRun use it. It currently can't, as the attribute doesn't cover "background-image" as FileRun uses, but only "img" tags.

We haven't ignored the orientation aspect, just didn't yet find the best solution for handle it. We'll try harder ;)

I haven't thought about the performance issue.

A possible solution would be to turn it within the browser, with a small JS script: https://stackoverflow.com/a/32490603/3207406 (for this to work, you will probably need to load it on js and then set the background-image attribute, like this: https://stackoverflow.com/a/34642144/3207406)

I would recommend setting a `data-exif-orientation` attribute based on the result of the call and let the CSS rotate the background using `transform` depending on this `data-exif-orientation` attribute.

So, what's the case here? One of the basic functions should be the correct alignment of the images, shouldn't it?!?

You can ask the same question to your camera manufacturer ;)


I understand your point, but still every software used by me (macOS, Windows, Nextcloud, several Android-Apps) display the pictures in the correct alignment - so I have to find an alternative to filerun, which is sad, because I really liked the web interface over nextcloud and Plex, because EXIF-Tags are well treated!

I agree with m.f - displaying the images with the correct orientation is such a basic functionality, it shouldn't take 2 years to fix. How about generating another set of thumbnails, large enough to provide proper resolution, and with the correct rotation, and displaying them instead of the full-size original?

You can set:

$config['thumbs']['output_small_max_filesize'] = 1024;

inside "customizables/config.php" (see http://docs.filerun.com/advanced_configuration).

That means that FileRun will no longer output the actual file for previews but always generate a resized preview. The process will autorotate the images based on EXIF.

You will however then complain about how slow image preview load, because generating resized previews of large images is not a quick process. (The generated previews do not get cached, because their size depends on the browser's size/screen resolution.)

Hey Vlad, thanks for coping with this issue!

I was wondering which previews are cached and which not and which are generated at all. In Nextcloud I can set a maximum width/height up to where previews are generated, so that I have several preview sizes to choose from depending on display size.  Wouldn't that be an option, at least an optional one, to just cache more sizes and chose the appropiate one (NC additionally works with upscaling to a given factor) and not to generate it on the fly?

P.S.: I would love to have the same logic of cached previews as NC anyway, so that I can merge the two preview cache folders :-)

P.S.S.: What does the command line function for generating previews (make_thumbs.php) do anyway if usally previews are not cached? Plus, it would be great to be able to provide a subfolder to that function!


As a workaround you can simply run

mogrify -auto-orient *.JPG

in the folder where your images reside. (You need to have ImageMagick installed.)

Source: https://stackoverflow.com/questions/19456036/detect-exif-orientation-and-rotate-image-using-imagemagick

Not a bug

In the meantime, all modern browsers have corrected this behavior and images, regardless of how they are loaded, they are displayed with the correct Exif orientation.