Certain portrait images misinterpreted as landscape

alex

Ran into a new issue with some portrait images of different sizes. See example here: https://code.adamilab.com/phototest/ Specifically, the first image of lupine flowers compared to the last four images of various flowers.

The first image is ₁₂ MP and portrait in orientation and gets previewed and displayed as it should. The second is ₅₀ MP and landscape in orientation gets previewed and displayed as it should. So far, so good.

Then, the final four images are a problem. Note that all six of the images in this gallery come from the same phone, albeit different camera sensors. The final four are ₅₀ MP images and do not get previewed or displayed correctly. Size-wise this is 1836 x 4080 for the first image vs 3672 x 8160 for the final four.

Note that I use the MP terms loosely, as this is what my phone says but it's a pretty crummy sensor so it is definitely not true 50 MP quality.

Note how the "broken" images actually display their dimensions on mouseover as 8160 x 3672, so I think Files Gallery is misinterpreting them as being landscape when they are portrait.

The browser (or at least mine) has no trouble with the distinction. A direct link to one of them shows up just fine as a portrait-oriented image: https://code.adamilab.com/phototest/20250531_172356.jpg

I poked around in settings to see if I was missing something obvious and cannot find anything. Looked for "rotation", "portrait", and similar search terms in the forum, nothing. I threw a much older version (0.9.12) up in its place and the same issue occurred, so does not seem to be something introduced in this version. I cannot recall seeing this before, but I don't take a ton of portrait-oriented images. Hoping it's an easy answer that I am just missing. Thanks!

Karl

alex I tested one of the images that appear wrong, and I can confirm that this looks like a bug related to image orientation (exif image orientation data stored in images). Files Gallery normally displays exif rotation correctly (see demo here), but it looks like there is something wrong with this specific orientation.

The thumbnail itself is actually created and rotated correctly, as you can see when you load it directly into browser. the problem is, the width and height attributes of the image have not been inverted, which is what we normally need to do when we detect images that are rotated by EXIF meta data. So the result in your case, is that although the thumbnail is tall, it displays cropped in a wide thumbnail (and therefore also looks jagged). And when clicking to view the image in popup, it also displays correct orientation, but the width and height have not been inverted.

I will look into it ...

In the mean time, your only solution would be to use a desktop tool like "ImageOptim" that compresses (lossless if you want) and ALSO corrects the physical orientation of your images, according to EXIF image orientation.

In a perfect world, all images should be correctly rotated physically, instead of cameras sometimes storing the "orientation" in an EXIF value inside the image, which doesn't match the width/height attributes of the physical image.

alex

Karl Thank you for looking into it. It is clearly not a common issue, I don't remember seeing it with any prior images (and I have used this phone before). I am hopeful there will be a clue in why the first image has no issues but the last ones do. Otherwise have gotten a lot of use out of the gallery since purchasing it, so this minor hiccup does not diminish my appreciation for your hard work. Cheers!

Karl

alex Indeed it's a very strange issue, as I can't see any technical difference between image #1 and image #3. Also, I have tests for all EXIF image orientation in the demo, and nobody has reported a problem like this before. I will check in-depth later today, as I can clearly see that dimensions for the incorrectly oriented images are not inverted as they should be.

Karl

alex Ok, I found out exactly what is happening here. Your images are massive, and exceed the estimated memory required for running PHP exif_read_data() on the images. This is explained in detail in the below post:
https://forum.files.gallery/d/743-autorefsresh-and-autoplay/15

After the issue in the post above was reported, I implemented a test that checks if server has sufficient memory to run the exif_read_data() on each specific image (dimensions). If we didn't do that, we run the risk of the the entire folder failing to load because of "insufficient memory" error, as you can read about in the post above.

So that is the reason, and also why the first image ₇.5 MP works, and the 3rd image ₃₀ MP doesn't. Basically, we can't know that this image is oriented by EXIF, because we can't extract the image EXIF information. Therefore, it will report as a 8160 X 3672 px (wide) image, whereas it's actually 3672 X 8160 px (tall) image, and the image is inserted into HTML at wrong dimensions

It might actually be that your server can run exif_read_data() on those images, but it could also fail, in which case the entire dir will fail to load. You can try yourself if you want to. Locate line 2212:

// get image Exif if we anticipate memory is sufficient
if($this->memory_sufficient_exif()) $this->image['exif'] = Exif::get($this->realpath);

Remove the check:

// get image Exif if we anticipate memory is sufficient
/*if($this->memory_sufficient_exif()) */$this->image['exif'] = Exif::get($this->realpath);

After editing the code, you would need make a change to the folder (add or rename a file) so that cache gets refreshed. You don't have to test this yourself of course, but I wanted to make it clear what is causing the issue, and that we can't just remove the memory check. Another solution would be to increase your servers memory_limit from 128M to a higher value, for example 256M.

alex

Karl That did it. I bumped the memory limit to 768M which solves the problem. Fascinating little bit of strange PHP behavior. I wonder if exif_read_data() is loading the entire thing in some extraordinarily inefficient way just to look for the exif data?

I agree with you on the importance of the memory check; that is surely why the gallery creation didn't break when I first loaded these images.

It will become more of an issue as MPs go up, but seems like this is PHP's issue to fix rather than yours. Appreciate the help!

Karl

alex Fascinating little bit of strange PHP behavior. I wonder if exif_read_data() is loading the entire thing in some extraordinarily inefficient way just to look for the exif data?

Indeed it was a strange issue, and I was also surprised to find out that exif_read_data() consumes an amount of memory proportional to the pixel dimensions of the image. One would assume it could just read image meta data, but that doesn't seem to be the case.

The fix is not optimal either, because it uses a very rough estimation of memory required, with a very safe margin to avoid errors in the script that loads the folder data. There is a fair chance that it might have worked on your side by just disabling if($this->memory_sufficient_exif()) and without increasing the memory limit. Did you try? Or did you just increase the memory limit without editing the code?

I have an idea for improvement in next update: Check image dimensions in Javascript after the image loads (both the thumbnail and large image in the popup), in which case we can detect if reported image dimensions are wrong (because of EXIF orientation). In this case, you might see a glitch after the image or thumbnail loads and the layout shifts to support correct orientation/aspect, but it would be minimal.

Other options would be to temporarily increase memory_limit programmatically, like we do when resizing large images. However, this doesn't seem safe or practical when looping through multiple images with different dimensions in a single dir.

alex

Karl I just increased the memory limit. I figured I would forget to make the same change in that file the next time I upload it to a new folder (and then in two years, having forgotten this incident, I'd again wonder why it was broken).

The Javascript method would probably work, assuming that they coded their EXIF reading function in a more sane way than PHP. It would I suppose be limited by the browser then, so on a modern machine (with many GB of RAM) one would not run into this unless a truly huge image was loaded.

I agree with you that the temporary memory limit increase seems a poor choice, especially if multiple images were involved.

Karl

alex I just increased the memory limit.

This is by far the best solution, but not everyone has the ability to increase the memory_limit.

alex The Javascript method would probably work, assuming that they coded their EXIF reading function in a more sane way than PHP. It would I suppose be limited by the browser then, so on a modern machine (with many GB of RAM) one would not run into this unless a truly huge image was loaded.

Actually, modern browsers will already automatically rotate images according to their EXIF. This is what we saw also in your case after clicking the images: the orientation was correct, but the image/width was wrong, which in turn made the images look distorted. In fact, if you loaded the images directly in new browser window, everything would seem correct, because width/height would be set automatically. The problem is, in Files Gallery, we need to know the width and height up front (from PHP) to be able to render the thumbnail and popup ... and if we don't know that the width and height should be inverted according to EXIF, then it will be wrong (as in your case).

So a workaround solution is to check width/height after the image loads, in case we find out that it has been re-oriented in browser by EXIF. We wouldn't do this up front or anything with Javascript, so there definitely wouldn't be any memory-related issues like in PHP. This workaround would only occur when 1. the image dimensions are larger than what we anticipate the servers memory_limit is capable of, and 2. the image is oriented by EXIF.

When the workaround triggers, it would cause a tiny shift in the layout after thumbnail loads and resizes. It would not cause any noticeable shift when loading the full size image.

Anyway, I'm sure that was much more information than you needed, but was good to write it down for future reference. I still need to implement the workaround. Thanks for reporting!

Karl

A fix for image orientation issues was added in latest release 0.14.0.
www.files.gallery/blog/files-gallery-0-14-0

Files Gallery will now check natural width and height of images after they load, and make corrections if required. This is basically a "workaround" to solve issues with width, height and orientation when these values are wrong or unknown up front.