Very Large Image creation strategies
Moderators: MtnViewJohn, chris, mtnviewmark
Very Large Image creation strategies
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
-- mark
- TorfusPolymorphus
- Posts: 27
- Joined: Sun Dec 28, 2008 2:16 pm
- Contact:
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.TorfusPolymorphus wrote: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).
maybe. size directive seems to interact with tile.hereld wrote: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.TorfusPolymorphus wrote: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).
- TorfusPolymorphus
- Posts: 27
- Joined: Sun Dec 28, 2008 2:16 pm
- Contact:
I do think it does what you need. Say we start with a scene like this:hereld wrote: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.
Code: Select all
startshape start
size [ s .5 x .5 y .5 ]
rule start {
CIRCLE { sat 1 b 1 }
}
Code: Select all
size [ s .5 x .5 y .5 ]
Is this what you're looking for?
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
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.
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 wrote:
I do think it does what you need. Say we start with a scene like this:Then addingCode: Select all
startshape start size [ s .5 x .5 y .5 ] rule start { CIRCLE { sat 1 b 1 } }
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.Code: Select all
size [ s .5 x .5 y .5 ]
Is this what you're looking for?
- TorfusPolymorphus
- Posts: 27
- Joined: Sun Dec 28, 2008 2:16 pm
- Contact:
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 wrote: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.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
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.
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.MtnViewJohn wrote: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.
does tile mode upset this?
quote
Lovely to see such a wonderful site. Thank you
think VECTOR graphics
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!!
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!!