Very Large Image creation strategies

[hereld]

i am trying to create images in the 100K x 100K range. one approach that i am tracking down is to make CF create 10K x 10K pieces of the larger image so that it doesn't run out of memory while rendering to the pngCanvas. i haven't yet found where in the code to define the coordinates of the sub-region. any ideas? (better still, is there some way to do something like this from the command line?)

-- mark

[TorfusPolymorphus]

Since version 2.2 there's the size command. It works like the tile command, but instead of wrapping around it simply crops the image to the given region. This should help if you run out of memory during drawing, although I guess all the shapes themselves have to be created nevertheless (even if they're not drawn).

[hereld]

Since version 2.2 there's the size command. It works like the tile command, but instead of wrapping around it simply crops the image to the given region. This should help if you run out of memory during drawing, although I guess all the shapes themselves have to be created nevertheless (even if they're not drawn).

hmm.... very promising. but it looks like it doesn't give a sub-section, but rather focuses on centering as far as i can tell. would like to create the shapes for 100K x 100K and then render only one of the hundred 10K x 10K sub-images. these could then be stitched back together after all hundred png files were created.

[hereld]

Since version 2.2 there's the size command. It works like the tile command, but instead of wrapping around it simply crops the image to the given region. This should help if you run out of memory during drawing, although I guess all the shapes themselves have to be created nevertheless (even if they're not drawn).

hmm.... very promising. but it looks like it doesn't give a sub-section, but rather focuses on centering as far as i can tell. would like to create the shapes for 100K x 100K and then render only one of the hundred 10K x 10K sub-images. these could then be stitched back together after all hundred png files were created.

maybe. size directive seems to interact with tile.

[TorfusPolymorphus]

hmm.... very promising. but it looks like it doesn't give a sub-section, but rather focuses on centering as far as i can tell.

I do think it does what you need. Say we start with a scene like this:

Code: Select all

startshape start

size [ s .5 x .5 y .5 ]

rule start {
	CIRCLE { sat 1 b 1 }
}

Then adding

Code: Select all

size [ s .5 x .5 y .5 ]

will render the lower left quarter of the circle. You get the other quarters by using all combinations of +-.5 for x and y. Of course you can get smaller subsections by using a smaller scale.

Is this what you're looking for?

[MtnViewJohn]

The size feature isn't really designed for this kind of output. You might get it to work but I bet that there would be artifacts at all of the edges. What is really needed is a new drawing canvas type that claims to be 100k x 100k pixels to the rendering engine but actually draws to a 10k x 10k subset. That way the image pieces would stitch together perfectly.

[hereld]

I do think it does what you need. Say we start with a scene like this:

Code: Select all

startshape start

size [ s .5 x .5 y .5 ]

rule start {
	CIRCLE { sat 1 b 1 }
}

Then adding

Code: Select all

size [ s .5 x .5 y .5 ]

will render the lower left quarter of the circle. You get the other quarters by using all combinations of +-.5 for x and y. Of course you can get smaller subsections by using a smaller scale.

Is this what you're looking for?

yes. this is at least qualitatively what i am looking for. i am checking into MtnViewJohn's concern that the edges might not be exactly correct with a few tests.

[TorfusPolymorphus]

The size feature isn't really designed for this kind of output. You might get it to work but I bet that there would be artifacts at all of the edges. What is really needed is a new drawing canvas type that claims to be 100k x 100k pixels to the rendering engine but actually draws to a 10k x 10k subset. That way the image pieces would stitch together perfectly.

Hm. Actually that's what I would've expected when using the size command. Is there a reason it doesn't work that way?

[MtnViewJohn]

The way Context Free works is that all of the shapes are calculated in a unitless coordinate space. As it generates each shape Context Free keeps track of the bounding box in this unitless coordinate space that contains all of the shapes. Then Context Free streams all of the shapes to a drawing canvas, but first it calculates a scaling and shifting affine transform that maps the bounding box in the unitless space to the bitmap with pixel units.

The size command tells Context Free to not bother calculating the bounding box. Instead the bounding box for drawing is specified by the size command. But this user-specified bounding box is in the unitless coordinate space, not the pixel coordinate space of the drawing canvas bitmap. The edge of the bounding box will almost certainly not align exactly with a pixel boundary. So I'm guessing that when the images are stitched together the edges will be noticeable.

Another issue that could cause edge artifacts is that small shapes that overlap the edges may be drawn on one side of the edge but get culled from the drawing list on the other side.

These two reasons are why I think it is better to implement this affect by subdividing the drawing operations in the pixel coordinate space.

[hereld]

The way Context Free works is that all of the shapes are calculated in a unitless coordinate space. As it generates each shape Context Free keeps track of the bounding box in this unitless coordinate space that contains all of the shapes. Then Context Free streams all of the shapes to a drawing canvas, but first it calculates a scaling and shifting affine transform that maps the bounding box in the unitless space to the bitmap with pixel units.

The size command tells Context Free to not bother calculating the bounding box. Instead the bounding box for drawing is specified by the size command. But this user-specified bounding box is in the unitless coordinate space, not the pixel coordinate space of the drawing canvas bitmap. The edge of the bounding box will almost certainly not align exactly with a pixel boundary. So I'm guessing that when the images are stitched together the edges will be noticeable.

Another issue that could cause edge artifacts is that small shapes that overlap the edges may be drawn on one side of the edge but get culled from the drawing list on the other side.

These two reasons are why I think it is better to implement this affect by subdividing the drawing operations in the pixel coordinate space.

thanks for the great explanation! i'd like to look into this. as i understand you, it would be appropriate to look at a pixel canvas (like pngCanvas) implementation as a guide. if the render has been made to specific pixel size, then i have a sense of what to do: bounding box maps to the full pixel space requested, but the size, x, and y parameters of some sibling to tile and size directives (perhaps clip) would define the sub-section to render -- determining the amount of memory to allocate and the clipping box for the rendering.

does tile mode upset this?

[Boorchmen]

Lovely to see such a wonderful site. Thank you

[jmil]

CF is amazing at drawing vector art primitives - squares and circles and the like. Rendering them to pixels is always going to be lossy. Why not save the vector art and then manipulate from there?

You should save your CF art as .svg which is a vector graphics format and so inherently infinitely scaleable. Then you can import it into something like Inkscape (Illustrator usually chokes on my large CF art images) and splice or render to pixels from there.

Out of curiosity, why do you need an image file that is sooooooo large?? Do you just want to zoom way in on certain areas or are you trying to print billboard or TimesSquare size? Is this for research or advertising? Really interested to know what this is for and what solution you come up with!!