Last modified: 2014-09-23 19:54:56 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 4854 - Image rendering and resizing daemon
Image rendering and resizing daemon
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
All All
: Low normal with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-02-04 03:15 UTC by Brion Vibber
Modified: 2014-09-23 19:54 UTC (History)
3 users (show)

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

python code (992.93 KB, application/gzip)
2013-12-17 08:31 UTC, Nemo
egg package (239.40 KB, application/octet-stream)
2013-12-17 08:31 UTC, Nemo

Description Brion Vibber 2006-02-04 03:15:38 UTC
We've kicked this idea around for some time but haven't yet implemented it.
It would be great to have a nice little daemon for doing image resizes safely:

* No more ImageMagick shell-character-exploit or buffer-overflow scares
* Reduce and unify library and subprogram dependencies for application servers
(vs varying versions of ImageMagick, librsvg, libart/cairo, freetype, etc)
* Integrate a nice SVG renderer like Batik
* Potential to isolate CPU and memory usage by running on separate boxes

* downscale PNG -> PNG
* downscale JPEG -> JPEG
* downscale GIF -> GIF
* rasterize SVG -> PNG
* The SVG renderer must be used in a restricted mode: a SVG must not be able to
include resources loadeded from disk or the network, as this could be a security
* Any alpha-transparent PNGs must set the background color chunk to white
to avoid weird unexpected colors in old versions of IE.
* Application servers should be able to communicate with the daemon by a
standard, easy to integrate protocol such as HTTP. A simple REST interface
is preferred over XML-RPC or SOAP.
* If in Java, should be possible to compile with Eclipse compiler and run
with GNU Classpath and an open-source VM, even if we use another VM in
production for performance preferences.

I'd like to see also:
* Better control over output format (grayscale staying grayscale, avoiding
wasted bandwidth etc)
* If possible, 'safe' memory usage for resizes of large PNGs as well as JPEGs.
Loading a 10kx10k pixel bitmap into memory to make a 100x100 thumbnail doesn't always end well.
* Other file formats welcome.

There are two main possibilities for data transfer:
* POST an upload of the source file, and receive the data back. MediaWiki
will deal with reading the file from disk and saving the thumbnail back.
* Send and receive pathnames (or partial pathnames). Daemon will handle
disk access, and simply return a file references.

The path references are likely more efficient, but may require sanitizing
for safety.
Comment 1 Michael Dale 2009-04-22 16:24:50 UTC
some comments posted here:
Comment 2 Sumana Harihareswara 2012-02-16 19:40:43 UTC
Zhe Wu wrote code to solve this problem for a 2009 GSoC project.

Zhe's status email:

Zhe's code:

Install instructions:
Comment 3 Nemo 2013-12-17 08:31:27 UTC
Created attachment 14118 [details]
python code

The repo was deleted from GitHub but is still available on pypi (190 downloads last month): attaching the package here in case it disappears there too.
Comment 4 Nemo 2013-12-17 08:31:49 UTC
Created attachment 14119 [details]
egg package

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