I though a bit more about it, and think it’s not a Kirby or GD issue after all.
The orientation info only makes sense in images taken straight from a camera. Camera manufacturers do this because rotating a photo in-camera before saving the file is ressource intensive, takes time, and would drain the battery.
When an image is modified in a graphic editor, there is no longer any doubt as to which orientation is correct: you edit and save it the way it should be looked at, with the top of the image at the top. That’s why most editors just strip the orientation info and re-save the image in its “normal”, intended orientation. A portrait 1600x1200 image with a “Rotate 90 CW” info then becomes a 1200x1600 one without any orientation info.
Now what should the thumb() function do? It has no way to know how the image will be displayed, so it shouldn’t try to “fix” the image and take orientation into account because:
- the function() can’t tell if we’ll only use thumbnails, or both thumbnails and the original image. Both should have the exact same orientation infos ;
- sometimes you may take a photo sideways and want to keep it that way. Automatically “fixing” it would give a wrong result ;
- orientation sensors sometimes give wrong informations when the camera is aimed towards the ground or sky.
So @R4ttlesnake, as you display you images in html pages and the untouched originals alone in a new window/tab, I believe the only way to get consistent results on your site is to rotate them before you upload them. It could be really quick, and lots of apps can do lossless jpeg rotations.
Edit: if Kirby offers post upload hooks someday, you may try to losslessly rotate the original image with something like jpegtran first, then create thumbnails.