Uploading iPhone JPG images with EXIF data causes unwanted file modifications.

[hbaumhardt]

Tested with several hundred images across two WP 6.1.1 sites one of which is vanilla with with no plugins active.

When an iPhone originated JPG file with EXIF metatadata is uploaded to the media library:

(1) file is renamed/recreated *-rotated.jpg

(2) dpi resolution is reset from 72 to 96 increasing file size.

(3) EXIF metadata is stripped off (or the original file is being replaced).

These are all unnecessary and unwanted actions. If this bizarre behaviour is core functionality, there needs to be a filter/action to disable/bypass/avoid it.

[azaozz]

Hi @hbaumhardt, welcome to Trac!

All of these are either expected behaviour or depend on what software is available on your server. When a "raw" image is uploaded (like a photo form a camera or a phone), WordPress prepares it for use on the internet.

The first thing that happens is to reduce the image size to a max of 2560px width or height. This also reduces the image file size to about 700-800KB. Original photos are anything from 3-4MB up to over 20MB which is not acceptable for use on internet.

The second thing that happens is to rotate the image if there is EXIF rotation information. This ensures the image and all of its sub-sizes are displayed correctly in all cases. If rotated, the -rotated suffix is added to the file name to distinguish it from the original.

Preserving EXIF data depends on whether ImageMagick is available on your server. This info is available in the Info tab in Tools -> Site Health.

Don't think the resolution setting affects image sizes. Browsers typically assume images are displayed at 96dpi for CSS purposes (even on high-res devices/screens), but the images are considered by their pixel dimensions.

These are all unnecessary and unwanted actions.

None of these will happen if you prepare the photos for internet use before uploading them, and ensure ImageMagick is available on the server.

Going to close this as "invalid" as all is expected behaviour or depends on the server. Feel free to reopen (with examples, etc.) if you believe WordPress is doing something incorrectly.

[hbaumhardt]

The first thing that happens is to reduce the image size to a max of 2560px width or height

This should not be happening with [ add_filter('big_image_size_threshold', 'return_false'); ] but it is:

Upload: 2582KbJpgImageWithEXIFdata.jpg 2582Kb
Result: 2582KbJpgImageWithEXIFdata-rotated.jpg 5171Kb

Upload: 4883KbJpgImageWithEXIFdata.jpg 4883Kb
Result: 4883KbJpgImageWithEXIFdata-rotated.jpg 6362Kb

The files are getting LARGER rather than just being left alone as desired.

The second thing that happens is to rotate the image if there is EXIF rotation information

(1) The images are uploaded already in the correct orientation so there should be no modification.
(2) Even if they were not, there should be an over-ride to avoid this unwanted "logic".

None of these will happen if you prepare the photos for internet use before uploading them

So WordPress is not able to accept image uploads direct from camera phones without molesting them by design ... is that in the specification ?

[hbaumhardt]

Additional information:

(1) Using the Wordpress default library with all native wordpress image resizing disabled.

(2) Uploading EXIF tagged JPG images of any size or orientation from Apple or Android devices works PERFECTLY with no image changes or manipulation by wordpress. Raw image files are preserved intact with metadata AS DESIRED. No additional ImageMagic libraries required.

(3) Except SOME (not all) portrait orientend images are converted to the *-rotated.jpg format which inflates the file size and strips metadata.

Affected images can originate from Apple or Android devices.
Affected images can be uploaded to WordPress direct from originating device or via PC browser.
Affected images can be of any size tested 10Kb to 10Mb
Affected images all have EXIF Orientation metadata e.g. [Rotate 270 degrees]
Not all images with EXIF Orientation metadata are affected.

So it looks like Orientation metadata is MOSTLY (not always) being used to refactor the image. Totally unnecessarily as the images start in the correct orientation.

If this is infact by design an exif/metadata ingore filter option would work around the issue.

[azaozz]

Replying to hbaumhardt:

So WordPress is not able to accept image uploads direct from camera phones

Exactly the opposite :)

WordPress attempts to make all uploaded images "Internet ready". Images uploaded directly from smart phones are generally too big (by file size and by pixel dimensions) to be used on the Internet.

This should not be happening with [ add_filter('big_image_size_threshold', 'return_false'); ] but it is:
Upload: 2582KbJpgImageWithEXIFdata.jpg 2582Kb
Result: 2582KbJpgImageWithEXIFdata-rotated.jpg 5171Kb

That is incorrect. From the example it seems the "Result" image was not resized, i.e. it is not Internet ready because the big_image_size_threshold was disabled. It was rotated as seems the EXIF Orientation data indicated it is not oriented correctly.

The file size depends on the JPEG compression setting and in most cases recompressing a photo makes it quite smaller. Not sure why the example shows a much larger file size. Generally that would happen if the uploaded image was already compressed a lot more, typically with compression setting of 50% or less.

Often photos taken with smart phones are not oriented properly as the phone was rotated when the image was taken. The browsers can rotate the image in such cases if the EXIF data is present. However not all images are viewed in browsers, and the EXIF data is not preserved when image sub-sizes are created with GD (this is a limitation of the GD library in PHP). To avoid showing incorrectly rotated images (sideways or upside-down) WordPress uses the EXIF "Orientation" data (when present) to rotate the uploaded image before making the sub-sizes.

So it looks like Orientation metadata is MOSTLY (not always) being used to refactor the image. Totally unnecessarily as the images start in the correct orientation.

WordPress would always rotate an uploaded photo when the EXIF Orientation is not 1 and the image is not "mirrored" (cameras do not produce mirrored images).

Of course if you dislike this behaviour you can use the existing filters to disable it. All filters are documented at ​https://developer.wordpress.org/reference/.

What is the bug that is being reported here?

[hbaumhardt]

As this is going nowhere best close it.

An inelegant brute force solution to unnecessary and unwanted EXIF.Orientation triggered image manipulation:

add_filter( 'wp_image_maybe_exif_rotate', '__return_null' );