Ticket #7042 (closed feature request: wontfix)

Opened 4 years ago

Last modified 5 months ago

Use exif rotation data when uploading pictures

Reported by: tieguy Owned by:
Priority: normal Milestone:
Component: Upload Version: 2.5.1
Severity: normal Keywords:
Cc: luis@…, dave@…

Description

When I upload a picture, the exif rotation data doesn't seem to be used. It should be.

Pretty sure flickr does this; I know gallery (gallery.menalto.com) does; all my local tools here respect it so I'd hate to have to modify the picture just to satisfy wordpress.

Otherwise, the gallery feature is shaping up nicely- well done.

(Doesn't help that there appears to be no way to do the rotation post-upload.)

Change History

  • Version set to 2.5.1
  • Cc luis@… added

comment:3   ryan3 years ago

  • Milestone changed from 2.7 to 2.8

Postponed to 2.8.

comment:4   ryan3 years ago

  • Owner anonymous deleted
  • Type changed from defect (bug) to feature request
  • Component changed from General to Gallery

comment:5   ryan3 years ago

  • Milestone changed from 2.8 to 2.9
  • Severity changed from normal to major
  • Component changed from Gallery to Upload
  • Severity changed from major to normal
  • Summary changed from exif rotation data not used when uploading pictures? to Use exif rotation data when uploading pictures

We can rotate the uploaded image before saving it (when exif rotation is set) then create thumbnail and other sizes. However that will modify the original image, remove exif data, etc.

Perhaps the better option is to rotate only the sub-sized images while creating them and leave the original intact. It's also possible to rotate the original with JS when displaying it.

(In [11746]) Use exif rotation data when creating sub-sizes of uploaded jpeg images, see #7042

comment:9 follow-up: ↓ 17   azaozz3 years ago

The replacement imagerotate() function is very slow with large images, it copies the image pixel by pixel. Perhaps we should do image rotate and flip only when it's available.

  • Cc dave@… added

comment:11 follow-up: ↓ 12   Viper007Bond2 years ago

Well, slow rotation is better than no rotation I think.

comment:12 in reply to: ↑ 11   azaozz2 years ago

Removed this temporarily pending better patch [11899].

Replying to Viper007Bond:

Well, slow rotation is better than no rotation I think.

By slow I mean really slow... For 1.2MB image it takes 0.2 sec. when imagerotate() is available and about 8 sec. otherwise, not even considering the server load. Don't think that's acceptable.

Honestly I disagree. 8 seconds is bad, but not terrible for sitting there looking at "crunching". I think the user expects that it could take a bit.

I'd very much agree... 8 seconds is quite acceptable as long as I've got something on the screen telling me why. That 8 seconds spent is going to be way better than my wife having her image end up sideways in her blog post, come complaining to me about it, having me walk her (again) through rotating it by hand in an image editor and re-uploading it, and I'd bet she would agree, too.

I think this is a really big deal for "regular human users". My mother is baffled and I'm preparing myself to explain exif data... :-)

  • Milestone changed from 2.9 to 3.0

comment:17 in reply to: ↑ 9   nacin2 years ago

It actually looks like this ticket was fixed in [11746]. Looks like there was some post-commit discussion but that's it. So fixed?

And/or the imagerotate() replacement is addressed in #10528.

Related: #11382

  • Status changed from new to closed
  • Resolution set to wontfix

Between this: (In [11746]) Use exif rotation data when creating sub-sizes of uploaded jpeg images, see #7042; and the addition of rotation post-upload in 2.9, I'm going to close this ticket as wontfix, since it's been open for 21 months but no one has added a patch. If someone wants to revisit, feel free to open when there's a patch to attach.

I have no objection, the other patches that have already been committed satisfactorily address this I think.

  • Milestone 3.0 deleted

This issue wasn't actually fixed as the change was reverted in [11899].

However, we have a newer ticket for this we can use - #14459

Note: See TracTickets for help on using tickets.