* Updated outputLocallyScaledThumb() and outputLocalFile() to handle changes in r106752.
In MediaTransformOutput:
* Added a storage path field to the transformation output object and set it in File::maybeDoTransform().
In File:
* Fixed maybeDoTransform() handling if repo member is not set and made it fully respect $wgIgnoreImageErrors.
In BitmapHandler:
* Don't set bogus path if TRANSFORM_LATER in doTransform() for deffered renderings.
- 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.
This is Bryan's patch from bug 30640 with a couple minor related changes, plus some unit tests.
This also addresses an issue with preventing too-big images from being scaled from r92279.
I also noticed that image magick's rotation support is broken in 6.3.7 (the version I had installed locally. I've since upgraded) I'm not sure if we should be doing something about that...
I did test this without both image magick, and gd (although only very briefly with gd) both seemed to work well. I didn't test any other image scalars.
Restructure and comment of ImageHandler::normaliseParams(). ImageHandler::normaliseParams() will now output both width/height as physicalWidth/Height, where width/height are the dimensions used by the browser, and physicalWidth/Height are the dimensions of the thumbnail that will be created. This allows keeping the use of unique dimensions for a specified thumbnail width, by forcing client side resizing of 1px-wide images with non corresponding height.
Also fixed a bug where the check for mustRender() was in an if statement where it should not have been.
* Added wfSuppressWarnings to Bitmap.php:
Notice: unserialize(): Error at offset 0 of 2 bytes in D:\www\MW_trunk\phase3\includes\media\Bitmap.php on line 685
to stop mostly irrelevent classes from getting it.
Also remove a method that is an exact duplicate of a base class (not sure whats with that).
This also coincidently fixes the issue with when a foreign file repo uses PagedTiffHandler
and the local one does not, and the builtin Tiff handler tries to treat the metadata as if
it was its own form.
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
