Page MenuHomePhabricator

Image rendering and resizing daemon
Closed, ResolvedPublic


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.

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:05 PM
bzimport set Reference to bz4854.
bzimport added a subscriber: Unknown Object (MLST).

sumanah wrote:

Zhe Wu wrote code to solve this problem for a 2009 GSoC project.

Zhe's status email:

Zhe's code:

Install instructions:

Created attachment 14118
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.


Created attachment 14119
egg package