>> Might I ask on what display are you using a 41000 x 41000 picture ?
>> It took more than a 4m x 3m advertisement poster with the fine details
>> of handheld publication (10 pixels/mm).
>
> The image is a very small galaxy of the following dimensions,
> ~41,000x41,000x10,000ly. Our current star grouping has ~12M coordinates (stars
> only) which are being placed as single unit (1ly) white spheres. I am mainly
> trying to generate the image for a top view. While I am normally rendering it at
> a max of 12800x10240 (which takes ~10hrs to finish rendering) the even larger
> image was desired so we could break down the exact locations better and allow
> extreme zooming to a specific coordinate (or at least the 2D representation of
> it).
>
> So basically it was an idea to get a ~1ly:1pixel representation of the galaxy in
> the image.
>
>
In that case, why not create a mosaic of smaller images that you can 
assemble and display as needed.
That way, you can have a collection of, say, 1000x1000 pixels tiles, 
with possibly a small overlap. You only have at most 4 images loaded in 
memory at any time.


Alain

Post a reply to this message

Le 05/10/2010 19:08, Warp nous fit lire :
> Le_Forgeron <lef### [at] freefr> wrote:
>> and keep in mind that when writing the final file,
>> you need yet another chunk because most libraries use a memory approach
>> too (but it is usually only 3 or 4 bytes per pixel), even if they
>> compress later the output before reaching the disk.
> 
>   Most image format read/write libraries support reading/writing the image
> in small portions at a time, for this precise reason. For example, pnglib
> only requires a few kilobytes of RAM to write even huge PNGs, and you can
> feed it pixel data in small groups.
> 
>   So converting the image to 8-bit-per-component RGBA and writing to PNG
> shouldn't be the problem (because the conversion can be done a few pixels
> at a time).
> 

You are correct.
But testing an empty scene (well, 1 camera, 1 light source) with a 20500
x 20500 size gives the following observations:
(-A -D)

memory used on system jumps to 9.6G at the render start.
It raises as it progress to 16G.
When file-write start, (1 & 1/4 active threads), memory stay at 16G.
Then drops to 9.1G and only 1 thread stays with 100% while the write
finishes... a delay might be observed once the write ends and before the
program exits (sometime).

The 25% thread might be some garbage collector... but it looks like
there is a memory leak while rendering (I would have expected all
allocation do have been done once all rendering threads have been
created (well, short of temporary objects like intersections stacks...)

6.4G is not a small increase.

Note to self: best WT values (for a huge & empty scene) of cpu
efficiency seems to be number of HTcores -1 (so the scheduler push them
full frequency). As soon as WT number reaches number of cores, they are
slowed down to approx 60% on the system chart. (thread collisions is
probable)

Post a reply to this message

> >
> In that case, why not create a mosaic of smaller images that you can
> assemble and display as needed.
> That way, you can have a collection of, say, 1000x1000 pixels tiles,
> with possibly a small overlap. You only have at most 4 images loaded in
> memory at any time.
>
>
> Alain

I am presently looking at that, using 8100x8100 tiles BUT I am worried about how
that will affect their orientation since I will have to reposition the camera in
every case to maximize usage of the 8100 but to somehow also have it match up
how it would look as if I was viewing the larger image.

To a prior recommendation about using boxes I think I can give that a shot to
see if it helps.

Post a reply to this message

>>>
>> In that case, why not create a mosaic of smaller images that you can
>> assemble and display as needed.
>> That way, you can have a collection of, say, 1000x1000 pixels tiles,
>> with possibly a small overlap. You only have at most 4 images loaded in
>> memory at any time.
>>
>>
>> Alain
>
> I am presently looking at that, using 8100x8100 tiles BUT I am worried about how
> that will affect their orientation since I will have to reposition the camera in
> every case to maximize usage of the 8100 but to somehow also have it match up
> how it would look as if I was viewing the larger image.
>
> To a prior recommendation about using boxes I think I can give that a shot to
> see if it helps.
>
>

If you are using an orthographic camera, you only need to move the 
camera up/down right/left .

If you use a normal perspective camera, then you can shear the camera 
using a matrix transform. In that case, you don't move the camera.



Alain

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> You are correct.
> But testing an empty scene (well, 1 camera, 1 light source) with a 20500
> x 20500 size gives the following observations:
> (-A -D)

> memory used on system jumps to 9.6G at the render start.

  With which version of POV-Ray? Currently 3.7beta does indeed allocate
RAM for the entire image. 3.6 shouldn't (when display is off).

-- 
                                                          - Warp

Post a reply to this message

Le 10/10/2010 09:20, Warp nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> You are correct.
>> But testing an empty scene (well, 1 camera, 1 light source) with a 20500
>> x 20500 size gives the following observations:
>> (-A -D)
> 
>> memory used on system jumps to 9.6G at the render start.
> 
>   With which version of POV-Ray? Currently 3.7beta does indeed allocate
> RAM for the entire image. 3.6 shouldn't (when display is off).
> 
I'm using the 3.7Beta of course.

Post a reply to this message