@fixme is simply not recognized by doxygen whereas @todo is used to
generate a nice ... todo list!!
Change-Id: If956c0a164373126ce48b791d45c56962034eecd
* 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
* (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.)
'Tugra Mahmuds II Big Size.gif' on Commons otherwise seems to eat as much CPU and memory as you can throw at it (1,876 × 1,500 pixel, file size: 4.36 MB, MIME type: image/gif)
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
* Changed display style: added a "more" link which expands a box for player selection.
* Allow return to the still image only display.
* Fixed Java detection in IE (I hope)
Elsewhere:
* Changed MediaTransformOutput::toHtml() parameters, now accepts a single associative array with well-defined elements. Allows OggHandler to distinguish between file download links and image description links.
* Made image links consistently have an anchor tag with class=image, instead of a mixture of image and internalParse.
* Made most images have a border=0 attribute, instead of just images on the image description page. Does not appear to adversely affect display at all, it was just convenient.
* Use the image name as the title attribute for the <a> tag, when an a caption was not given by the user
* Block centering by the auto margins method in ImageGallery
* Fixed complete breakage of the thumbnail on upload conflict feature
* TODO: test DjVu
* Added support for configuration of an arbitrary number of commons-style file repositories.
* Split Image.php into filerepo/File.php and filerepo/LocalFile.php
* Renamed Image::getImagePath() to File::getPath()
* Added initial support for timestamp-based file fetching (OldLocalFile), to be expanded upon by aaron.
* Changed the interface for Image/File object creation: use wfFindFile() or wfLocalFile() depending on semantics
* ImageGallery::add() now accepts a title object as the first parameter
* Moved file handling operations on upload from SpecialUpload to File
* Removed path-related functions from ImageFunctions.php. Removed static path accessors from File.
* Added a Content-Disposition header to thumb.php output
* Improved thumb.php error handling
* Updated the unit test suite to kind of partially work with modern computers. RunTests.php doesn't work just yet. Fixed an actual regression that the test suite detected -- moved some defines to Defines.php where they will be loaded consistently.
