User "Bryan" posted a comment on MediaWiki.r97671. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97671#c23158 Commit summary:
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation - sets an image's reported width/height to the logical form (portait image reports itself as portait) - everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box) - fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want - removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it - ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path. Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated. Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659. Needs merge to 1.18. Comment: This will return the rotated image size even if the scaler doesn't support rotation, right? _______________________________________________ MediaWiki-CodeReview mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
