[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