[Pixman] Very Large PNGs

Frederik Ramm frederik at remote.org
Thu Feb 24 16:43:28 PST 2011


Soeren Sandmann wrote:
> I think it should be safe to use size_t in create_bits() along with new
> functions pixman_multiply/add_overflows_size() if you want to fix this.

I guess I'll try my hand at that.

> However, not that pixman is still limited to 16.16 bits of coordinate
> space in various places, so you wouldn't gain that much. This 16 bit
> limitation is something that we would like to get rid of, however. 
> Out of curiosity, exactly how large are the images you are trying to create?

The first use case I had was actually only very slightly above the 
limit; I tried to generate something that was about 24000x32000 pixels.

> In cairo 1.10, you actually can create a 16 bit image, and it is stored
> internally in a 16 bit data type.

I'll have a look at that too and perhaps use whichever way gives me the 
least pain. The 16-bit data type should allow bitmaps of roughly 32k x 
32k without hitting the coordinate space limit, that would already be an 
advantage, and the loss of colour space would probably not be too bad 
for my application.

Just to give some background, what I'm doing is creating raster street 
map images from OpenStreetMap data; I generate an SVG and have it 
rasterized with rsvg/cairo. If you want a full map of a large city where 
all the road names are still readable, you quickly approach the sizes 
I'm talking about here. I know, printing this stuff would mean we're 
doing 1200 dpi on an A0 printer, but there are indeed use cases where 
I'm asked to produce such extra-large images. As I said, I can get 
around the limits by tweaking the SVG viewport, rendering a few tiles 
and pasting them (and one day I'll probably script that...) but somehow 
I sat there and wondered why I have to do that if the machine has 
endless RAM and 64 bit addressing.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the Pixman mailing list