[wp-trac] [WordPress Trac] #14459: Rotate Full Size Images on Upload

WordPress Trac noreply at wordpress.org
Thu Aug 15 15:18:03 UTC 2019


#14459: Rotate Full Size Images on Upload
-------------------------------------------------+-------------------------
 Reporter:  mrroundhill                          |       Owner:
                                                 |  mikeschroder
     Type:  enhancement                          |      Status:  reviewing
 Priority:  normal                               |   Milestone:  5.3
Component:  Media                                |     Version:  3.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by pbiron):

 Replying to [comment:77 azaozz]:
 > > If an uploaded image has an EXIF orientation of anything other than
 "normal" (e.g., 2, which means "flipped"), should we modify the image
 accordingly on upload?
 >
 > Yes. Thinking it is best to support all "orientations" that are possible
 in EXIF, including "flip" and "mirror".

 I think so as well, but stated it as a question to avoid expanding the
 scope of the ticket in my patch.

 > Going through all previous comments, my opinion is that this patch
 shouldn't introduce preserving of EXIF data in the images produced by GD.
 There seems to be a possibility of corrupting the rotated image file if we
 "patch it" on binary level.

 I was going off what @mikeschroder said in [comment:55 #55], which I
 interpreted as his opinion that we should **not** do rotation (or
 flip/etc) on upload if we couldn't also preserve EXIF (and/or IPTC) in GD.

 > Unfortunately there is no PHP extension/library that can (100% reliably)
 write EXIF in JPEGs. Thinking it is better to avoid any possibility of
 corrupting the user's images rather than try to do that by writing
 directly to the files. This is also consistent with the current behavior.

 I spent a little time trying to put a WP core wrapper around the
 [https://github.com/pel/pel Pel] library, for general EXIF/IPTC editing
 within core.  But quickly decided it wasn't worth it (at least for now,
 especially considering the effort that would be necessary to do the UI for
 such an editor).

 But my implementation of writing the binary orientation tag in
 WP_Image_Editor_GD` is heavily influenced by the way Pel does it.

 What are the chances of WP putting some pressure upstream to get GD to
 preserve EXIF/IPTC/etc?

 > Of course it will preserve the EXIF when using ImageMagick. Thinking we
 may also need to fix the image dimensions in the EXIF when we change it
 from portrait to landscape, or the other way round. Not sure how useful it
 would be.

 I don't think that's necessary...the dimensions stored in the original
 image assume the orientation has been applied.

 Another thing I brought up in
 [https://wordpress.slack.com/archives/C02SX62S6/p1564666146129300 #core-
 media chat] a few weeks ago was:

 > suppose you've got an oriented image with an embedded thumbnail.  You
 upload it, it gets rotated and intermediate sizes are created (after
 rotation).  If you then download the files from the upload dir to a
 Windows machine and look at them in Explorer, you'll notice that some of
 them are oriented correctly and others are not.  Because depending on the
 size of the embedded thumbnail, Explorer displays it

 So, when images are rotated/flipped/etc, should we extract the embedded
 thumbnail, rotate/flip/etc it and re-embed  it?  This applies whether the
 image is rotated/flipped/etc on upload or done interactively by a user.
 99% of users will never noticed, but just thought I'd mention it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/14459#comment:80>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list