Hope I did this in an ok fashion. svn merge --re-integrate was giving me issues
so I just essentially over-wrote my working copy with the version at img_metadata.
Scaler type is "imext". Rotation is supported.
Logic mostly copied from transformImagemagick() and ported to Imagick calls.
Resizing animated gifs is broken; it only shows the first frame and I can't find out why it does not work, but otherwise it is fully working.
* Added JS variabele wgFileCanRotate. If anybody knows a way to make certain variables only available to certain modules, please tell me, could not find it.
* Added JsJpegMeta as mediawiki.util.jpegmeta
* Made BitmapHandler::getScaler and BitmapHandker::canRotate static
* Bumped style version
On r79845 I submitted a wrong commit summary, here is it for reference:
(bug 6672) Images are now autorotated according to their EXIF orientation. Following the Flickr example, this only affects thumbnails, with the source unrotated.
* Introduced BitmapHandler::canRotate() and BitmapHandler::getRotation() to check if rotation is supported and what the amount of rotation is
* Factored out scaler determination into BitmapHandler::getScalerType()
* ImageMagick uses the -auto-orientation option
* GD uses imagerotate()
* Unconditionally show the thumb size on the image page, don't know why this wasn't shown for SVGs etc.
Backwards compatible, if not set to an array, applies to all uploads. If set to an array, per upload type maximums can be set, using the file and url keys. If the * key is set this value will be used as maximum for non-specified types.
names as the program name.
I'm just not exporting those variables here, but we need to support them in Windows, too.
We could use putenv() but that seems ugly (and risky). A better solution would be to have
wfShellExec() call proc_open() with a modified environment.
A POSIX shell is required to accept variable assignments before the command so we shouldn't
have problems on any UNIX-like system.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_01
* (bug 24824) Support ImageMagick 6.5.6-2+ JPEG decoder size hint, to reduce memory usage when such an ImageMagick is used for scaling.
* Removed -size option since it doesn't act as a JPEG decoder size hint with recent ImageMagicks, and it may cause undesired behaviour in the future since it's documented to do something different now.
* Disable multithreaded behaviour in recent ImageMagick, to avoid a deadlock when a resource limit such as $wgMaxShellMemory is hit.
* Fixed some comments.
Replaces WMF live hack.
Tested bug 23148 and wildcards in filenames (was broken) using a patched convert. With a manual unit test (no convert), tested all branches of the new functions except wfIsWindows() == true.
The way the logic and the defaults were before, it was basically impossible for animations with more than 12 frames to reach the "only thumbnail first frame" codepath; this surely cannot have been intended.
Also mention r64691 in release notes.
r54746 "Update formatting for r54745"
r54745 "Added crop support for inline images."
r54748 "Making demon happy (adding public/protected to function definitions) and add some comments along the way."
Several issues:
* Implementation is ImageMagick-specific, no support for GD backend
* Specification syntax is pretty ugly and non-obvious imo... [[File:foo.jpg|<width>px|<left>x<top>x<width>x<height]]
* Crop syntax seems to be tied to pixels... I _presume_ source pixels? This would break if a file is re-uploaded with a new size.
* In general I'm very leery of tacking on more infinite-options-in-infinte-combinations for image rendering; our treatment of resizing already has implications for CPU and disk usage and this just adds another level of arbitrary-rendered horror. ;)
I'd much rather we move towards limiting the number of rendered variants we have, not increase them... IMO cropping would be better served with an interface allowing for explicit, visible cropping which creates either a new saved version, or a 'cloned' virtual file which can be referred to by name... and more importantly, uses of it would be trackable so that if crops needs to be updated they can be cleanly.
* Creates a new media handler for GIF files, and extracts metadata such as duration, whether or not the GIF is looped, and the number of frames.
* Uses the extracted metadata for the long file description.
* Considers number of frames in the calculation of image area (multiplies by width and height to get the "time-area", or so to speak).
After this patch is deployed, the work-around to disable GIF scaling on Wikimedia sites can be eliminated.
Also add pretty-printing of GPS coordinate values and correct display of altitude / destdistance reference values.
(We really should redesign the FormatExif class so that the "GPS*Ref" values can be combined with their parent values, but this will do for now.)
