Last modified: 2014-11-17 09:21:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 25990 - Add VIPS image scaling support to MediaWiki
Add VIPS image scaling support to MediaWiki
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.17.x
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.vips.ecs.soton.ac.uk/
:
Depends on:
Blocks: 28135
  Show dependency treegraph
 
Reported: 2010-11-18 13:06 UTC by Bryan Tong Minh
Modified: 2014-11-17 09:21 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bryan Tong Minh 2010-11-18 13:06:15 UTC
VIPS support should be added to MediaWiki. VIPS is a free image processing system. It is good with large images (images larger than the amount of RAM you have available), according to its website http://www.vips.ecs.soton.ac.uk/.

This would solve our 12.5MP limit for PNGs and other large files.


I believe that this has been discussed with somebody from WMF, most likely Tim, and that person I believe had done some tests with it.
Comment 1 Jeff G. 2011-02-14 03:56:02 UTC
Bug 24984#c13 seems to indicate that Tim supports it.  Lack of support for >12.5MP images, including PNG and TIFF, is negatively impacting multiple projects' scalability. VIPS implementation should save much RAM on the image scalers, allowing them to be more efficient and effective in RAM bottleneck situations.  I have reverted the unexplained downgrade in importance.
Comment 2 Mark A. Hershberger 2011-02-18 22:30:23 UTC
Jeff, Priority settings are explained here: http://www.mediawiki.org/wiki/Bugmeister/Bugzilla
Comment 3 Bryan Tong Minh 2011-03-18 23:11:27 UTC
It's done as extension VipsScaler (r84281), but needs a bit of workaround for non RGBA images as VIPS is broken. I already know the workaround of greyscale images, but I'm waiting on the reply of the maintainers for palette based images.
Comment 4 Bryan Tong Minh 2011-03-20 15:41:47 UTC
The palette and grayscale handling has been fixed in the latest unreleased VIPS version, so this is done.
Comment 5 Tim Starling 2011-03-20 23:18:29 UTC
(In reply to comment #1)
> Bug 24984#c13 seems to indicate that Tim supports it.

My initial comments about VIPS were on bug 23258.
Comment 6 Bryan Tong Minh 2011-03-21 18:47:53 UTC
I've changed to im_shrink in r84471. The problem however is that due to rounding, the results may be inaccurate, i.e. images of 179px wide instead of 180px. The result is then that the browser upsizes the image again.

Other options would be im_affine, but that uses a bilinear interpolation, which if I understand correctly is causing poor results similar to im_resize_linear.
Comment 7 Tim Starling 2011-03-21 23:42:16 UTC
(In reply to comment #6)
> I've changed to im_shrink in r84471. The problem however is that due to
> rounding, the results may be inaccurate, i.e. images of 179px wide instead of
> 180px. The result is then that the browser upsizes the image again.

There's 53 bits of precision in a floating-point number, you should be able to manipulate these tiny integers without rounding errors.

	/* Prepare output. Note: we round the output width down!
	 */
	...
	out->Xsize = in->Xsize / xshrink;
	out->Ysize = in->Ysize / yshrink;

typedef struct im__IMAGE {
	...
	int Xsize;
	int Ysize;

If you offset the destination sizes by 0.5px, then the output size should always be accurate. 

You need to add sharpening. I discussed sharpening on bug 23258. Note that sharpening is only necessary for images which are resized by significant factor, see $wgSharpenReductionThreshold.

For small images that are resized to a size that is only slightly smaller, you should use a VIPS function that has interpolation. For PagedTiffHandler, we could get away with ignoring this case, but if we use VIPS to scale all images, then we have to think about every possible case.
Comment 8 Bryan Tong Minh 2011-03-23 22:07:12 UTC
Fixed the scaling in r84635.

I was made aware of the vipsthumbnail program. This uses the sharpening that is also done in IM. See <http://www.vips.ecs.soton.ac.uk/index.php?title=What%27s_New_in_7.22#vipsthumbnail>
Comment 9 Tim Starling 2011-03-25 02:01:54 UTC
(In reply to comment #8)
> Fixed the scaling in r84635.
> 
> I was made aware of the vipsthumbnail program. This uses the sharpening that is
> also done in IM. See
> <http://www.vips.ecs.soton.ac.uk/index.php?title=What%27s_New_in_7.22#vipsthumbnail>

The problem with vipsthumbnail is that it stores the uncompressed image. For a large image, it could take gigabytes of disk space. ImageMagick does this also, that's one of the reasons we want to get rid of it.
Comment 10 Jeff G. 2011-03-25 20:41:40 UTC
(In reply to comment #9)
> The problem with vipsthumbnail is that it stores the uncompressed image. For a
> large image, it could take gigabytes of disk space. ImageMagick does this also,
> that's one of the reasons we want to get rid of it.

Can either one be made to use a compressed filesystem for storage, or modified to store compressed images?
Comment 11 Bryan Tong Minh 2011-03-28 16:28:37 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Fixed the scaling in r84635.
> > 
> > I was made aware of the vipsthumbnail program. This uses the sharpening that is
> > also done in IM. See
> > <http://www.vips.ecs.soton.ac.uk/index.php?title=What%27s_New_in_7.22#vipsthumbnail>
> 
> The problem with vipsthumbnail is that it stores the uncompressed image. For a
> large image, it could take gigabytes of disk space. ImageMagick does this also,
> that's one of the reasons we want to get rid of it.

Well, we'll have to do that anyway for non random accessible images (PNG, non tiled TIFF); they need to be converted to a .v file on disk, and as far as I know .v is uncompressed.
So if that is your objection to VIPS we need to find another solution, such as writing a PNG reader that supports random access. Should be possible as the PNG format is line based (but I don't know about zlib).
Comment 12 Max Semenik 2011-03-28 16:58:07 UTC
(In reply to comment #11)

> So if that is your objection to VIPS we need to find another solution, such as
> writing a PNG reader that supports random access. Should be possible as the PNG
> format is line based (but I don't know about zlib).

libpng supports line-by-line reading. As the matter of fact, VIPS uses it to handle PNGs. I uses it for my pngds rewrite, which stopped on downscaling.
Comment 13 Tim Starling 2011-03-28 22:29:53 UTC
(In reply to comment #12)
> libpng supports line-by-line reading. As the matter of fact, VIPS uses it to
> handle PNGs. I uses it for my pngds rewrite, which stopped on downscaling.

Right, VIPS can buffer several lines from libpng, do a block average, and then write out a line of output. Almost no intermediate storage space is required. That's why we want it.

Sharpening is done on the downscaled image, not the original image. It's feasible to store the downscaled unsharpened image so that it can be fed into another run of VIPS or into ImageMagick. We just want to avoid storing the uncompressed unscaled image.
Comment 14 Bryan Tong Minh 2011-04-12 22:01:44 UTC
I poked a bit at sharpening in r85207. It still looks a bit worse than ImageMagick, even though the convolution matrix should match the IM sharpening parameters.

As for the libpng thing, PNG is not marked as PIO in VIPS, so it might be that it will just try to decompress the entire file into memory. Somebody should look into the peak memory usage when scaling PNGs. I have no clue on how to do so unfortunately.
Comment 15 Tim Starling 2011-04-13 04:40:37 UTC
(In reply to comment #14)
> As for the libpng thing, PNG is not marked as PIO in VIPS, so it might be that
> it will just try to decompress the entire file into memory. Somebody should
> look into the peak memory usage when scaling PNGs. I have no clue on how to do
> so unfortunately.

Using the same source image as my tests in bug 23258, except pre-converted to PNG, the memory usage was 18MB for VIPS, and 411MB for ImageMagick. Memory usage in VIPS was low even if I used interlaced encoding in the source image. 

Note that im_tiff2vips and im_jpeg2vips are also marked "WIO", but reading TIFF and JPEG images uses a small amount of memory nonetheless. I think file format handlers are a special case.
Comment 16 Tim Starling 2011-04-13 06:41:09 UTC
As for measuring peak memory usage, check out my blog post on the subject: 

http://tstarling.com/blog/2010/06/measuring-memory-usage-with-strace/

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links