Hello...

In 3.5beta (february release), I have a memory allocation "problem".
I try to render an animation of Mars, using the very high
NASA resolution map
(maps.jpl.nasa.gov) of the planet's surface. It is a huge JPEG,
corresponding to
a 800 Mo uncompressed image.
I use a 1.3GHz T-Bird, with 768 Mo RAM, several (4-5) Go swap space, and
Win Me.
I can work on the image under Corel PhotoPaint, for instance, even to
build the
image, which means opening three RGB gray-level images and the final
merged
color image. No problem (except that it goes quite slow, swap of course
...).
Pov Ray tell me : unable to allocate 1 590 000 000 bytes.
Why ? The regular compile is not able to use swap space ?
Maybe a well-known fact : I am definitely not an expert in mallocs...
Thanks !

Gilles

Post a reply to this message

> In 3.5beta (february release)

Have you experienced such problem with 3.1 ?
(BTW each beta has a number, you are talking 11 probably)

> Pov Ray tell me : unable to allocate 1 590 000 000 bytes.

Are you sure allocation problem is connected with image maps ?
IIRC there is no problem with high quality maps from nasa in POV.

> Maybe a well-known fact

Maybe source of your script (try to keep it as small as possible) and url to
image could help.

ABX

Post a reply to this message

In article <3C7CF4BB.206760DA@obs.univ-lyon1.fr> , Gilles ADAM 
<ga### [at] obsuniv-lyon1fr>  wrote:

> Pov Ray tell me : unable to allocate 1 590 000 000 bytes.
> Why ?

Because applications can't use more than 2 GB each (or less, 2 GB is the
maximum for current Windows versions, Win ME might even support only 2 GB
total).  This one allocation is already 1.5 GB, and if another GB or so is
already used by POV-Ray, there simply isn't enough memory available.

    Thorsten

Post a reply to this message

> > In 3.5beta (february release)
>
> Have you experienced such problem with 3.1 ?
> (BTW each beta has a number, you are talking 11 probably)

Yes, release beta11. I must confess I did not try 3.1g... I shall do that. I
use to work with the latest MegaPOV.

>
>
> > Pov Ray tell me : unable to allocate 1 590 000 000 bytes.
>
> Are you sure allocation problem is connected with image maps ?
> IIRC there is no problem with high quality maps from nasa in POV.

I do not know... See, please, T.F.'s reply, below.

> Maybe source of your script (try to keep it as small as possible) and url to
> image could help.

See reply to T.F. below, please.

Thanks !

Post a reply to this message

Thorsten Froehlich wrote:

>  applications can't use more than 2 GB each (or less, 2 GB is the
> maximum for current Windows versions, Win ME might even support only 2 GB
> total).  This one allocation is already 1.5 GB, and if another GB or so is
> already used by POV-Ray, there simply isn't enough memory available.

Ok, so things are clear. I did not suppose PoV was using so much memory  for
parsing,
independently of the need for a large array for the image. Here is the script
I used
(unfortunately without the images, even URLs, as the final color image is not

on the WEB, you have to rebuild it from the three channel images provided by
NASA.
I changed the image type from JPEG to uncompressed TIFF, and this reduced the
memory
need from 1.5Gb to 1Gb; but PoV is still unhappy with that...
The script is simplified, for test purpose, but still shows the same
behaviour; I do not
think it contains anything strange :

 #include "colors.inc"
#include "shapes.inc"

global_settings { assumed_gamma 1.5 }

#declare clock1=0.35;

#declare sol = 1.8;

#declare rter = 200;
#declare diurne0 = 295;
#declare ecliptic = <23.5,0,0>;
#declare saison = <0,20,0>;

#declare theta = acos(2*(0.5-clock1));
#declare theta0=3*pi/2;
#declare a = 6;
#declare b = 8;

camera {
    angle 60
    up <0,1,0>
    right x*image_width/image_height
    #declare xC = a*rter*cos(theta+theta0) -2.4*(b-a)*rter;
    #declare yC = 0;
    #declare zC = b*rter*sin(theta+theta0);
    location < xC, yC, zC+1.5 >
    look_at 0
}

// Soleil :

#declare soleil = light_source { 0 color sol*White
                                 looks_like { sphere { 0,10
                                                     pigment { color rgb
<1,1,0.8> }
                                                     finish { ambient 1 }
                                                     }
                                            }
                               }

object { soleil translate 100*<20, 2, 0> }

// Planete :

#declare Planete = sphere { 0, rter
                            pigment {image_map {tiff
"d:\temp\mars_thr50.tif"   // 11520x5760x24, OK
                            // pigment {image_map {tiff
"d:\temp\mars_vhr.tif"     //  23040x11520x24,

// unsufficient memory
                                                map_type 1
                                                interpolate 2 }
                                      }
                            finish {ambient 0.1 diffuse 0.7}
                            no_shadow
                          }

object { Planete
         rotate <0, diurne0 - 360*clock1, 0>
         rotate ecliptic
         rotate saison
       }


Thanks a lot, anyway !

PoV is wonderfull, anyway ...

Gilles

Post a reply to this message

In article <3C7D2FF2.F2522864@obs.univ-lyon1.fr> , Gilles ADAM 
<ga### [at] obsuniv-lyon1fr>  wrote:

> #declare Planete = sphere { 0, rter
>                             pigment {image_map {tiff
> "d:\temp\mars_thr50.tif"   // 11520x5760x24, OK
>                             // pigment {image_map {tiff
> "d:\temp\mars_vhr.tif"     //  23040x11520x24,
>
> // unsufficient memory

First of all, you should really use Targa (or PNG) as format because for TIFF
images POV-Ray right now will always allocate a transmit channel.  So with
that alone, your big image requires one GB, not including whatever the TIFF or
JPEG libraries may be allocating to decompress the image.

Further, if you are using such a high resolution, may I assume you are also
trying to render an image with a size that will actually benefit from an input
image of this size?  If so, you also have to add memory for the output image
and so on and so on.

If you want to avoid the problem, your only solution is to get (access to) a
64 bit system, that is any current Compaq Alpha, IBM Power, Sun Sparc, SGI
Mips or HP PA-RISC system and then recompile POV-Ray 3.1g for one of those (or
compatible systems).  Of course you can also wait for a final release of
POV-Ray 3.5 and compile its source code, but either way, a 32-bit processor is
simply not up to the data size you want to handle :-(

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> First of all, you should really use Targa (or PNG) as format because for TIFF
> images POV-Ray right now will always allocate a transmit channel.  So with
> that alone, your big image requires one GB, not including whatever the TIFF or
> JPEG libraries may be allocating to decompress the image.

OK... I read things about PoV maybe going to remove TIFF support. Sounds
strangefor me, as TARGA is far less used than TIFF in the real world, but if the
TIFF library
is unreliable ... For PNG, I am still cautious, as I am not sure, for instance,
that every
browser understands all the features of this format, like transparency. But this
is
unrelated to the present problem, of course. I do use PNG as image maps in PoV,
sometimes.

> Further, if you are using such a high resolution, may I assume you are also
> trying to render an image with a size that will actually benefit from an input
> image of this size?  If so, you also have to add memory for the output image
> and so on and so on.

In my actual script, I switch several times between low, medium and high
resolution planetmaps. This is because I build a MPEG 1 movie, with a Mars flyby,
starting and ending
at, say, 8 Mars radiuses, with a slow, very low-altitude (a few tenths of km) fly
above Valles Marineris.
So I really use the high resolution, for some parts. The final movie format is
what I want, but to keep
it smoothly running on reasonnable UCs (like mine, just above 1GHz, with
middle-class
graphics card) I choose a conservative 640x480 pixels. It is already impressive
...
I use such animations for various level courses.
By the way, I would like to try MPEG 2, but have not found a really useable free
or not-too-expensive
codec.

> If you want to avoid the problem, your only solution is to get (access to) a
> 64 bit system, that is any current Compaq Alpha, IBM Power, Sun Sparc, SGI
> Mips or HP PA-RISC system and then recompile POV-Ray 3.1g for one of those (or
> compatible systems).  Of course you can also wait for a final release of
> POV-Ray 3.5 and compile its source code, but either way, a 32-bit processor is
> simply not up to the data size you want to handle :-(

My next system maybe a 64bit, but, right now, I have access to 32 bit ones
(Windows or Linux;
I stick to Windows, just from lazyness : it is so easy... And the rendering speed
should not be
significantly different, as it is only marginally OS-dependant, from tests I
made; in my case,
faster disks would be a great improvement).
By the way, with the ~11kx6k image, parsing time is round 1.5 minute, rendring
time 6 sec.

Ok, I think I know everything now  ;-)

Thanks a lot !

Gilles

Post a reply to this message

> If you want to avoid the problem, your only solution is to get (access to) a
> 64 bit system, that is any current Compaq Alpha, IBM Power, Sun Sparc, SGI
> Mips or HP PA-RISC system and then recompile POV-Ray 3.1g for one of those (or
> compatible systems).  Of course you can also wait for a final release of
> POV-Ray 3.5 and compile its source code, but either way, a 32-bit processor is
> simply not up to the data size you want to handle :-(

Unfortunatly radiosity doesn't work on 64 bit systems the last time I tried it. :(
Pov 3.1 compile under AIX)

Thomas

Post a reply to this message

Gilles ADAM wrote:

> By the way, I would like to try MPEG 2, but have not found a really
> useable free or not-too-expensive
> codec.

Just thought I would jump in here... There have been a couple threads 
concerning encoding mpeg2 animations in povray.unix .  The Linux utilities 
used are free.    Follow-ups to p.u

-- 

David
smuchrusher <at> ameritech <dot> net
ICQ#: 118347772

8:26am up 1 day, 4:28, 4 users, load average: 3.68, 3.47, 3.36

Post a reply to this message

Thorsten Froehlich wrote:

> First of all, you should really use Targa (or PNG) as format because for TIFF
> images POV-Ray right now will always allocate a transmit channel.  So with
> that alone, your big image requires one GB, not including whatever the TIFF or
> JPEG libraries may be allocating to decompress the image.

Second reply  to the same mail :
I switched from TIFF to TGA, and it works ! With the same resolution and
the same color depth; no more memory limit problem...
I should now stay below the 2Gb barrier, thanks Mr TrueVision/TGA !
And thanks everybody for the help.
Gilles
PS: I use now uncompressed TGA, but it was already uncompressed TIFF...

Post a reply to this message