Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Updates for EXIF rotated photos in trunk & 1.18

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


brion at pobox

Sep 20, 2011, 3:54 PM

Post #1 of 3 (372 views)
Permalink
Updates for EXIF rotated photos in trunk & 1.18

One of the long-awaited minor features that has finally come in during the
1.18 development cycle is resolving old bug 6672, natively supporting photos
where EXIF metadata specifies a non-default orientation.

This is very common in photos taken with digital cameras; a portrait-mode
image may be saved at the low-level as a 4x3 framebuffer with an orientation
tag stating it must be rotated 90 or 270 degrees (or occasionally an
upside-down photo needing to be rotated 180 :) While most photo-editing
applications understand this metadata natively and will simply show the
image at its natural size, web browsers don't -- and neither did the
server-side processing that MediaWiki was doing.

Bryan Tong-Minh did most of the earlier work on this a few months ago, which
is much to be commended!

In response to a couple issues noticed on test2.wikipedia.org (bug 31024,
bug 31048) I've made some tweaks to make it work more consistently. From now
on the image's width & height properties will be set to the logical size,
taking the orientation into account. This makes thumbnail resizing more
consistent (sometimes we got wrong sizes because the requested bounding box
would end up applied to the original physical size) and also makes the
orientation change transparent to API clients, such as other wikis using
ForeignAPIRepo (aka 'InstantCommons'). Clients won't need to know or care if
an image uses EXIF rotation; it'll simply always be presented and reported
as at its natural logical size.

I've applied these fixes to trunk, REL1_18, and 1.18wmf1 -- phpunit test
cases have been updated, but it's still conceivable something could be wrong
so please do test. :)


Note that any exif-rotated photos you've uploaded under the old code will
need to be purged to update their file metadata & clear out any old thumbs,
or they'll continue to possibly render wrong.


https://bugzilla.wikimedia.org/show_bug.cgi?id=6672
https://bugzilla.wikimedia.org/show_bug.cgi?id=31024
https://bugzilla.wikimedia.org/show_bug.cgi?id=31048

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


robla at wikimedia

Sep 20, 2011, 4:38 PM

Post #2 of 3 (358 views)
Permalink
Re: Updates for EXIF rotated photos in trunk & 1.18 [In reply to]

Fantastic...thanks for jumping on this Brion! And Reedy, thanks for
pushing this out!

So, this code should be live on http://test2.wikipedia.org plstestkthxbai :)

Rob


On Tue, Sep 20, 2011 at 3:54 PM, Brion Vibber <brion [at] pobox> wrote:
> One of the long-awaited minor features that has finally come in during the
> 1.18 development cycle is resolving old bug 6672, natively supporting photos
> where EXIF metadata specifies a non-default orientation.
>
> This is very common in photos taken with digital cameras; a portrait-mode
> image may be saved at the low-level as a 4x3 framebuffer with an orientation
> tag stating it must be rotated 90 or 270 degrees (or occasionally an
> upside-down photo needing to be rotated 180 :) While most photo-editing
> applications understand this metadata natively and will simply show the
> image at its natural size, web browsers don't -- and neither did the
> server-side processing that MediaWiki was doing.
>
> Bryan Tong-Minh did most of the earlier work on this a few months ago, which
> is much to be commended!
>
> In response to a couple issues noticed on test2.wikipedia.org (bug 31024,
> bug 31048) I've made some tweaks to make it work more consistently. From now
> on the image's width & height properties will be set to the logical size,
> taking the orientation into account. This makes thumbnail resizing more
> consistent (sometimes we got wrong sizes because the requested bounding box
> would end up applied to the original physical size) and also makes the
> orientation change transparent to API clients, such as other wikis using
> ForeignAPIRepo (aka 'InstantCommons'). Clients won't need to know or care if
> an image uses EXIF rotation; it'll simply always be presented and reported
> as at its natural logical size.
>
> I've applied these fixes to trunk, REL1_18, and 1.18wmf1 -- phpunit test
> cases have been updated, but it's still conceivable something could be wrong
> so please do test. :)
>
>
> Note that any exif-rotated photos you've uploaded under the old code will
> need to be purged to update their file metadata & clear out any old thumbs,
> or they'll continue to possibly render wrong.
>
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=6672
> https://bugzilla.wikimedia.org/show_bug.cgi?id=31024
> https://bugzilla.wikimedia.org/show_bug.cgi?id=31048
>
> -- brion
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


bryan.tongminh at gmail

Sep 21, 2011, 1:08 AM

Post #3 of 3 (352 views)
Permalink
Re: Updates for EXIF rotated photos in trunk & 1.18 [In reply to]

On Wed, Sep 21, 2011 at 12:54 AM, Brion Vibber <brion [at] pobox> wrote:
> I've applied these fixes to trunk, REL1_18, and 1.18wmf1 -- phpunit test
> cases have been updated, but it's still conceivable something could be wrong
> so please do test. :)
>

Great work Brion!


Bryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.