What could cause this? I’m drawing a blank on it. The only stuff I’ve found online so far, is about the iPad/iPhones, who treat image rotation Exif data differently… but this is occuring in Chrome, FF and Safari for me… so I’m wondering if it goes deeper than that.
I also looked into the possibility that maybe a CSS rule was doing the rotation, but I can’t see anything
At first, I thought maybe it was the CDN causing the issues (using maxcdn), but even with the local file its having the same issue.
We do pass the original images via jpgtran to optimize them, and also image::magick’s convert command to shrink them down. But that being said, I would have expected the image here to be sideways as well, if that were the cause:
Yeah, its really bizarre I’m sure it can’t be a jpgtran issue, as that doesn’t do anything with orientation - and imagemagick, I’m sure it can’t be that doing it either - as I’ve been using that for 10+ years, and never had a problem like this
Basically, converting the uploaded image into a max size of 1000x1000. People on our site have a habit of uploading 5000x5000 pics, and they kill disk space!
I can’t see how that command could be breaking it though?
I’m also not sure we could correct the Exif programmatically, by detecting the issue at source? (its entirely possible the user had a bad file they uploaded too!)
As you say that command should not cause a problem.
I’m also not sure we could correct the Exif programmatically, by detecting the issue at source?
How will you know which file is correct and which is wrong?
It seems a bit strange to use jpgtran and Imagemagick, I suppose you do not have the original photo if it is being uploaded by the user? Could you ask the photo uploader to send you the photos via email so you could carry out some tests as anything else is speculation.
How will you know which file is correct and which is wrong?
My thoughts exactly
It seems a bit strange to use jpgtran and Imagemagick,
I’m using jpgtran to remove exif headers we don’t need - as we had images that were 100kb for a 100x100 image (due to having a ton of location, meta, etc etc, which was useless to us) … then we do the resize into the respective sizes we need
I suppose you do not have the original photo if it is being uploaded by the user? Could you ask the photo uploader to send you the photos via email so you could carry out some tests as anything else is speculation.
Already ahead of ya Just waiting to hear back from them.
Just out of interest -thumbnail will remove all the file data except the colour profile as will -resize wxh -strip and would save you one step. Although not very helpful if there is some data you want to keep.
Ah cool - Is that a simple case of just replacing “resize” with “thumbnail” ? That would certainly help from a programing point of view, as it means I wouldn’t need to run jpgtran as well
Yeah for sure TBH, its not happening on a ton of images - but it is getting more common. It’ll be interesting to see if the original image has the same issue (if so, then it could be something to do with the device it was taken on, in which case we’ll just have to fix them up as we find them - which would be a sod)
Sorry I took so long to get back on this. For some reason, the person didn’t reply to my email asking for the original! Anywho, on a totally different job - I just came across the same problem.
I’m pretty sure its an iOS issue - but I’m not too sure why it happens. Any suggestions would be much appreciated
BTW - I’m hoping it comes out ok (I didn’t do any resizing, but it looks like the forum may well have - as the original was 1mb, not 250kb, as is showing here)
