It seems the issue is created in the front-end of Admin.

TLDR:

• Uploading image with Exif orientation flag = 6 (means: image requires rotation of 90 degrees clockwise)
• When resizing is switched on in Admin
  • Resulting uploaded image is being rotated 180 degrees clockwise
  • Exif remains unchanged: orientation flag = 6

Environment:

• Grav v1.6.26
• Admin v1.9.15
• Image downloaded from here
• Windows 10, WSL 1.0, Ubuntu 20.04

Test 1: no resizing in Admin

pagemedia:
  resize_width: 0

Steps:

• front-end
  • Upload image to page (with new name to prevent caching artefacts).
  • The thumbnail in upload field is rotated 180 degrees clockwise
• back-end
  • At breakpoint in AdminPlugin::getSubscribedEvents()
    • Image stored in $_FILES['file']['tmp_name']
      • Image data as in original
      • Exif orientation as original
  • Finished upload
    • Image stored in page folder
      • Image data as original
      • Exif orientation as original
• front-end
  • Save page
• backend
  • Hitting breakpoint gregwar Common::resize()
• front-end
  • The thumbnail in upload field is rotated 90 degrees anti-clockwise (same as original)

Test 2: with resizing in Admin

pagemedia:
  resize_width: 1500

Steps:

• front-end
  • Upload image to page (with new name to prevent caching artefacts).
  • The thumbnail in upload field is rotated 180 degrees clockwise
• back-end
  • At breakpoint in AdminPlugin::getSubscribedEvents()
    • Image stored in $_FILES['file']['tmp_name']
      • Image data rotated 180 degrees clockwise
      • Exif orientation as original
  • Finished upload
    • Image stored in page folder
      • Image data rotated 180 degrees clockwise
      • Exif orientation as original
• front-end
  • Save page
• backend
  • Hitting breakpoint gregwar Common::resize()
• front-end
  • The thumbnail in upload field is rotated 180 degrees clockwise

Thanks Pamtbauu, that's my experience too.

what version grav and admin is this and could you provide the images ur using please

@ricardo118 Added the following to my post containing test script:

Environment:

• Grav v1.6.26
• Admin v1.9.15
• Image downloaded from here
• Windows 10, WSL 1.0, Ubuntu 20.04

Ok Guys, this is a 2 pronged attempt to resolve the issue.. Please test latest 1.10 branch of admin with 1.7.0 branch of Grav.

First thing, was @w00fz removed the exif library and code we had to solve this before. For some reason, this was causing it to try to fix things twice! so an image that was flipped 180 was flipped correctly, then flipped again, to be 360deg and appear broken. We're not sure how/why it works without the exif.js library as we don't see anything in the changelog to reflect why this would break things all of a sudden.

Next, after we removed this I noticed that the PHP side of things was only handling the fixOrientiation stuff when rendering via markdown. This had the effect of the thumbs being flipped around, but when used in a page it was correct. However, when used via twig, it was no longer correct! I moved the logic out of Excerpts into a lower-level of the ImageMedium object. This appears to have resolved the issues i was seeing with my own test images plus the ones from here:
https://github.com/recurser/exif-orientation-examples

However, I cannot seem to get the large (8.2mb) Gucci bag example from above (https://dl.dropboxusercontent.com/s/31qijg0s3fp99gj/2020-07-02%2011.42.12.jpg?dl=0) to 100% work. thumbnail is on it's side, but when you use it in content, it's fine... So still trying to track down what's going on here.

TLDR: Compared to previous test:

• No resizing: Same results as previous test.
• With resizing: Images are being rotated 90 degrees clockwise. In previous test 180 degrees clockwise.

Installation:

• Installed Grav 1.7.0-rc14
• $ cd user/plugins/admin
• $ rm -rf *
• $ git clone -b 1.10 https://github.com/getgrav/grav-plugin-admin.git .

Used 'Gucci' image downloaded from here

Test 1: no resizing in Admin

pagemedia:
  resize_width: 0

Steps:

• front-end
  • Upload image to page (with new name to prevent caching artefacts).
  • The thumbnail in upload field is rotated 90 degrees clockwise
• back-end
  • At breakpoint in AdminPlugin::getSubscribedEvents()
    • Image stored in $_FILES['file']['tmp_name']
      • Image data as in original
      • Exif orientation as original
  • Finished upload
    • Image stored in page folder
      • Image data as original
      • Exif orientation as original
• front-end
  • Save page
• backend
  • Hitting breakpoint gregwar Common::resize()
• front-end
  • The thumbnail in upload field is rotated 90 degrees anti-clockwise (same as original)

Note: Results are the same as before fix.

Test 2: with resizing in Admin

pagemedia:
  resize_width: 1500

Steps:

• front-end
  • Upload image to page (with new name to prevent caching artefacts).
  • The thumbnail in upload field is rotated 90 degrees clockwise
• back-end
  • At breakpoint in AdminPlugin::getSubscribedEvents()
    • Image stored in $_FILES['file']['tmp_name']
      • Image data rotated 90 degrees clockwise
      • Exif orientation as original
  • Finished upload
    • Image stored in page folder
      • Image data rotated 90 degrees clockwise
      • Exif orientation as original
• front-end
  • Save page
• backend
  • Hitting breakpoint gregwar Common::resize()
• front-end
  • The thumbnail in upload field is rotated 90 degrees clockwise

Note: Images are now rotated 90 degrees clockwise. Previous test was 180 degrees clockwise

i appreciate the thorough testing but please don’t use the Gucci image. As i stated there is something wrong with that image that is causing issues. please test with the images i linked to in the github repo. those test all 8 rotation and flip combinations.

@rhukster Ran the test using image Portrait_6.jpg, which has the same orientation (portrait) and rotation (90 degrees anti-clockwise) as the Gucci image.

Results: Both images are handled the same. The image data has been rotated 90 degrees clockwise, and Exif remains the same as original.

Also:

• Both images show same Exif in online Exif extractor http://metapicz.com
• Both images show the same Exif in Gimp.
• Both images are correctly displayed in Windows Explorer
• Both images are correctly displayed by Chrome
• Both images are correctly displayed by Microsoft Photo app
• Both images are correctly displayed by Microsoft Paint
• The above makes me doubt if it is a problem with the Gucci image...

I'm thinking you didn't update the admin to latest 1.10 branch? that's not the behavior I'm seeing.

How do you check if image is correctly processed?

I created the following installation:

• Installed Grav 1.7.0-rc14
• $ cd user/plugins/admin
• $ rm -rf *
• $ git clone -b 1.10 https://github.com/getgrav/grav-plugin-admin.git .

Did I forget anything maybe?

/user/plugins/admin/CHANGELOG.md contains:

v1.10.0-rc.15

mm/dd/2020

1. • Disabled the EXIF library for Dropzone for fixing the orientation as it was getting applied twice #1923

that should be correct. make sure your cache is cleared to pick up the latest JS then.

This is what i get when i upload. These are the canvas generated thumbnails created by dropzone. All look correct:

Then when I click 'save', these are the ones generated by Grav via the listPageMedia call:

When i drag the thumb into the editor either raw or with cropzoom operation, and click 'preview', it appears correct in the browser. Even the Gucci one:

BTW admin image resize is definitely causing the thumbs to be broken, will look a that after. For now i want to find out why the Gucci image is not working fully.

oh btw, make sure you have this on in System -> Media -> Fix Image Orientation:

Ok, I committed another Grav fix that addresses the specific issue with the Gucci image. That one was related to a file stream that was causing the EXIF to come back as invalid. This is sorted now.

The other issue for resizing is due to a bug that exists in DropZone code specifically related to resizing of images on upload and EXIF orientations. We had to fork Dropzone for now to address this, and we also created a PR, so hopefully that will get fixed down the line. dropzone/dropzone#1876

I've set the "Fix orientation automatically" to Yes by default for 1.7, but this will need to be set on your installs... Other than that, this combination of fixes in Grav + Admin will be released very soon as RC15.

How do you check if image is correctly processed?

• Please be advised that, since recently, browsers (Firefox, Chrome) also "fix" the orientation based on the Exif in the image. This may add some confusion.
• The display of the images in Admin are not a good representation of their correctness.

For example:

• Using the same installation as before
• With resizing switched on

  pagemedia:
    resize_width: 1500
  

• With auto fix orientation switched off

  images:
    auto_fix_orientation: false
  

Results in Admin after clicking 'Save': All looks well

When hitting the 'preview' button next to the image in Admin, the browser shows the following:

Windows Explorer shows:

When opening the saved file in Gimp, it shows the data has been rotated, but the Exif is not corrected.

With resizing switched off:

• With resizing switched off

  pagemedia:
    resize_width: 0
  

The image are shown as follows in Admin after clicking 'Save':

well i don't know what to say at this point. I am not having the issues with latest Grav + Admin as long as i have auto_fix enabled with both regular and resized images. The images are correct in canvas (dropzone upload), page media list (on save), in the filesystem, as well as in the browser.

In fact i worked on this all afternoon with Djamil and after much digging and testing, we came up with this solution that works for both of us in all scenarios.

I'm at a loss that you are still having this issue. I'll be releasing this version of stuff tomorrow and perhaps we can get some wider testing.

Do you have php-exif support enabled btw? that's the only thing i can think of at this point.

Also check your Grav logs, as I enabled some error handling during fixOrientation() that previously silently failed.

In a previous post I asked what way you check the validity of the images, since you only shared Admin screenshots.
Test were done with the previous installation and were only intended to show that the images shown in Admin do not necessarily reflect the images stored on disk.

Sorry for the confusion created. Maybe I could have been more clear...

I am in the progress of cloning the latest Admin 1.10 and Grav 1.7 repos and redo the tests.

TLDR: All seems to be working well with the latest clones of Admin (branch 1.10) and Grav (branch 1.7)

Thanks for the enormous efforts you have invested in this issue!

Test results with resizing switched on:

New installation:

• $ mkdir site-orientation2
• $ cd site-orientation2
• $ git clone -b 1.7 https://github.com/getgrav/grav.git .
• $ bin/grav install
• $ git clone -b 1.10 https://github.com/getgrav/grav-plugin-admin.git .
• $ bin/gpm install login

Test:

• Resize switched on:

  pagemedia:
    resize_width: 1500
  

• Fix orientation switched on as per the default:

  images:
    auto_fix_orientation: true                     # Automatically fix the image orientation based on the Exif data
  

Results in Admin after clicking 'Save': All looks well

When hitting the 'preview' button next to the image in Admin, the browser shows the following:

Windows Explorer shows:

When opening the saved file in Gimp, it shows the orientation metatag has been removed.

Phew!!! Glad it's now working as expected.

@danjames68 Would you mind installing the latest Grav 1,7 and Admin 1.10 as soon as they are released and test for your use-case and environment? If you're eager, you might try and clone their latest branches 1.7 and 1.10 as I described above.

Note: You won't need the fixOrientation function in Twig anymore, since it is set as default behavour in system.yaml.

Hi Andy and hi Pamtbaau - thanks so much for this. I've installed latest grav and cloned the Admin 1.1 and it all works as expected. I really appreciate the time everybody put in - I'll be putting some money in the Open collective box...