Fix image orientation regression on mac, turn on exif-based rotation in image documents for chromium
Created attachment 170539 [details] Patch
Pasting from irc: if x and y are 0, it's the same as previously, and otherwise it's always adding what's missing for a identity matrix (e.g. "-1 0 0 -1" gets a +2x, +2y because that's missing to get "1 0 0 1", "0 1 1 0" gets +x-y, -y+x" to get "1 0 0 1" etc)
Comment on attachment 170539 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=170539&action=review > Source/WebCore/platform/graphics/ImageOrientation.cpp:35 > +AffineTransform ImageOrientation::transformFromDefault(const FloatRect& drawnRect) const Confused. Why were changes necessary here? Please explain in the ChangeLog. :)
Comment on attachment 170539 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=170539&action=review >> Source/WebCore/platform/graphics/ImageOrientation.cpp:35 >> +AffineTransform ImageOrientation::transformFromDefault(const FloatRect& drawnRect) const > > Confused. Why were changes necessary here? Please explain in the ChangeLog. :) I tried to explain in the changelog. Before r132384, the images were always drawn at the origin (i.e. x = y = 0). In the chromium port, and after r132384 in the apple port too, that not true, so this function needs to be updated to handle arbitrary origins. You'll note that when you set x = y = 0 in the formulas below, you get the old formulas back.
Created attachment 170632 [details] Patch
It sounds like people prefer the alternative fix approach in bug https://bugs.webkit.org/show_bug.cgi?id=100401 . If that gets landed, the bug here becomes WontFix.
https://bugs.webkit.org/show_bug.cgi?id=100401 landed. There's https://bugs.webkit.org/show_bug.cgi?id=100414 to switch ImageOrientation to rhs coordinates, which would have the same effect as this patch.