"normdoering" <nor### [at] yahoocom> wrote in message
news:web.3dd0294eeff88682cbb77c320@news.povray.org...
> image_width and image_height ... I thought they were just for raytracer
> output, not importing pictures. Seem pretty useless for my goals.
>
> Oh well, more reason my mesh makers will ultimately have to be done as a
> separate program.

Would seem so. Yep, those are for/from the output resolution. If you were to
use the same numbers for both input and output image sizes maybe useful,
otherwise no. Also not so for automation of the renders. There's always
something POV-Ray *can't* do.  :-)

Post a reply to this message

I'd like to try this out a bit. I loaded a file that was 720 x 480 and set
the xPixels and yPixels to 720 x 480 but the image only appeared in the
upper right quadrant. Now I see the Resx and Resy  factors. Should I set
xPixels and yPixels to the exact size of the input file and leave Resx as =
xPixels and the same for Resy to get the image to fill the screen?
thanks much
D.




; // actual size takes too long to render
#declare Resy = yPixels/2;
"normdoering" <nor### [at] yahoocom> wrote in message
news:web.3dcf7587da80818e1dffbb4f0@news.povray.org...
> In my quest to write some macros that can turn special 2D pencil drawings
> into mesh2 models (like human figures and faces that are photographically
> real) I've figured out how to read an imported picture pixel by pixel.
>
> However, I'd also like to know how to get a picture's size in pixels using
a
> POV feature (if there is any) because right now I'm reading those from
> Corel and typing them in.
>
> Here's the scene file:
>
> //=================================================================
> #version 3.5;
> #include "colors.inc"
> global_settings { assumed_gamma 1.0 }
> // ----------------------------------------
>
> camera
> { location  <0, 0, -850.0>
>   look_at   <0, 0, 0>
>   angle 35
> }
> background {rgb <0.5, 0.5, 0.5>}
>
> //No light source needed to test these assumptions uses ambient finish
> // -----------------------------
> // the test:
> //==============================
> #declare xPixels = 271; // 271 is number of pixels in x dimension
> #declare yPixels = 496; // 496 in y dimension
> // ---> How do I get these numbers without having to declare them?
> // That is, how can I ask for the size of an image in pixels?
>
> #declare ScX = 1;    // scale has to be declared because it's shared with
> the
> #declare ScY = 1.83; // #while loop. Difference in scale because the
> function
>                      // wants to create a square picture and fills the
> square
>                      // area from (x,y) coordinates (0,0) to (1,1)
> regardless
>                      // of the image's original size in pixels.
>
> // these mark how the picture goes exactly to upper right quadrant
> cylinder {-200*x, 200*x, 1 pigment {rgb <1,1,0>} finish {ambient 1}}
> cylinder {-200*y, 200*y, 1 pigment {rgb <1,1,0>} finish {ambient 1}}
>
>
> #declare MyTesti = function    // In order to get the HF_ macros to read
> { pigment                      // imported pictures they have to be
>   { image_map                  // declared this way.
>     { jpeg "12.jpg" map_type 0 // <----
>       once
>     }
>     scale <ScX, ScY, 1>
>   }
> }
> #declare MyTest = function {MyTesti(x,y,z).grey} // then redeclared
>                                                  // because
>                                                  // they're the wrong data
>                                                  // type
> #declare Resx = xPixels/6; // actual size takes too long to render
> #declare Resy = yPixels/6; // so I divide it by 6
>
> #declare incx = 1/Resx;
> #declare incy = 1/Resy;
>
> #declare yloc = 0;            // This loop can read a picture one pixel at
a
> #while (yloc < ScY + 0.0001)  // time.
> #declare xloc = 0;
> #while (xloc < ScX + 0.0001)
>
> sphere
>  { <xloc*50, yloc*50, -5> 0.5
>    pigment { rgb <MyTest(xloc,yloc,0), MyTest(xloc,yloc,0),
> MyTest(xloc,yloc,0)>}
>    finish {ambient 1}
>  }
>
> #declare xloc = xloc+incx;
> #end
> #declare yloc = yloc+incy;
> #end
> //=================================================================
>
> The above code will read a picture, potentially pixel by pixel, and copy
it
> to a structure made of spheres.
>
> -- normdoering
>
>
>

Post a reply to this message

Dennis Miller wrote:
>I'd like to try this out a bit. I loaded a file that was 720 x 480 and set
>the xPixels and yPixels to 720 x 480 but the image only appeared in the
>upper right quadrant. Now I see the Resx and Resy  factors. Should I set
>xPixels and yPixels to the exact size of the input file and leave Resx as =
>xPixels and the same for Resy to get the image to fill the screen?
>thanks much
>D.

Be careful, a 720 x 480 picture might crash a small memory system at full
resolution.

But, yes, to read every pixel you do not divide xPixels and/or yPixels to
get Resx and Resy. Those variables were added to make things go faster but
at the price of not doing exactly what I said, reading every pixel. Reading
every pixel is for later when I'm ready to make a highly detailed mesh. I
don't need it yet. I just need to know how ... which I do now.

If you want to read every pixel, you might consider a different image,
smaller.
Also, you might want to use ambient finish and turn off all the lights --
POV makes these light buffers that took a long time to do when I tried it.

In a couple days I'll be posting some code that will make the mesh and cut
holes in the picture.

Thanks for your interest. Maybe you can help me understand how to do what
I'm trying to do by keeping the questions coming.

Post a reply to this message

In article <web.3dd31b13eff88682d5c1896a0@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> Be careful, a 720 x 480 picture might crash a small memory system at full
> resolution.

Huh? That would have to be a really tiny memory system. Storing that in 
memory as 24 bits per pixel, 8 bits per component, would take less than 
1MB of memory. Most systems *display* at 800*600 or above, mine is at 
double that. I can't see that causing problems on any system that is 
used to run POV. As a mesh, it could be considered to be 345,600 
vertices, at 3 float values each, about 4MB with some additional memory 
for other mesh info.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Well in fact, I did run into a memory error: "Cannot allocate XXX bytes for
[something or other.]" (I can run it again to check.
I have 1 GB RAM on the system and have to scale the ResX and Resy down by a
factor of 4 (ResX/4) before it will even run!

BEst,
D.


"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <web.3dd31b13eff88682d5c1896a0@news.povray.org>,
>  "normdoering" <nor### [at] yahoocom> wrote:
>
> > Be careful, a 720 x 480 picture might crash a small memory system at
full
> > resolution.
>
> Huh? That would have to be a really tiny memory system. Storing that in
> memory as 24 bits per pixel, 8 bits per component, would take less than
> 1MB of memory. Most systems *display* at 800*600 or above, mine is at
> double that. I can't see that causing problems on any system that is
> used to run POV. As a mesh, it could be considered to be 345,600
> vertices, at 3 float values each, about 4MB with some additional memory
> for other mesh info.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message

In article <3dd43763@news.povray.org>,
 "Dennis Miller" <dhm### [at] attbicom> wrote:

> Well in fact, I did run into a memory error: "Cannot allocate XXX bytes for
> [something or other.]" (I can run it again to check.
> I have 1 GB RAM on the system and have to scale the ResX and Resy down by a
> factor of 4 (ResX/4) before it will even run!

What are you doing? I've done much more memory intensive stuff on this 
machine, which has 384MB. I used 1024*1024 height fields on a machine 
with 96MB.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>In article <web.3dd31b13eff88682d5c1896a0[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> Be careful, a 720 x 480 picture might crash a small memory system at full
>> resolution.
>
>Huh? That would have to be a really tiny memory system. Storing that in
>memory as 24 bits per pixel, 8 bits per component, would take less than
>1MB of memory. Most systems *display* at 800*600 or above, mine is at
>double that. I can't see that causing problems on any system that is
>used to run POV. As a mesh, it could be considered to be 345,600
>vertices, at 3 float values each, about 4MB with some additional memory
>for other mesh info.

You might want to try it yourself before you guess. There's more getting
stored in memory than the picture. When I did my picture at full resolution
it took over an hour and there were things coming up like "vista buffer,"
"light buffer," etc. I don't quite know what those are.... but those are
spheres I'm using not pixels.


--normdoering

Post a reply to this message

web.3dd4d018eff8868284f6eaf50@news.povray.org...
> You might want to try it yourself before you guess. There's more getting
> stored in memory than the picture.

Exactly, which is why memory use related to pixel size of the picture is non
significant for usual screen sizes.
If you have a memory use problem with a tiny 720 x 480 picture then it's
probably a scene-related problem, not a image size one. Memory use *** can
*** be related to image size in some cases (it sure is with radiosity for
instance), but such a small size it's extremely unlikely to cause problems.

Particularly, if you have light buffers running amok, just turn them off
using the "-UL" switch, or reduce the number of lights in your scene.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

In article <web.3dd4d018eff8868284f6eaf50@news.povray.org>,
 "normdoering" <nor### [at] yahoocom> wrote:

> You might want to try it yourself before you guess. There's more getting
> stored in memory than the picture. When I did my picture at full resolution
> it took over an hour and there were things coming up like "vista buffer,"
> "light buffer," etc. I don't quite know what those are.... but those are
> spheres I'm using not pixels.

It wasn't a guess, it was a calculation, finding the number of pixels 
and multiplying by the size used for each one. Using spheres will of 
course use more memory...I didn't go far enough up the thread to find 
out spheres were being used.
But I have done similar things. One particular scene swapped out over 
200MB to disk on this system, with 384MB RAM. It can get impractically 
slow, but shouldn't crash.

The vista and light buffers are to optimize camera and light rays, so 
they only test objects that might be hit. They do take a fairly large 
amount of memory, especially in this type of scene with lots of objects, 
but you can turn them off.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>In article <web.3dd4d018eff8868284f6eaf50[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> You might want to try it yourself before you guess. There's more getting
>> stored in memory than the picture. When I did my picture at full resolution
>> it took over an hour and there were things coming up like "vista buffer,"
>> "light buffer," etc. I don't quite know what those are.... but those are
>> spheres I'm using not pixels.
>
>It wasn't a guess, it was a calculation, finding the number of pixels
>and multiplying by the size used for each one. Using spheres will of
>course use more memory...I didn't go far enough up the thread to find
>out spheres were being used.
>But I have done similar things. One particular scene swapped out over
>200MB to disk on this system, with 384MB RAM. It can get impractically
>slow, but shouldn't crash.
>
>The vista and light buffers are to optimize camera and light rays, so
>they only test objects that might be hit. They do take a fairly large
>amount of memory, especially in this type of scene with lots of objects,
>but you can turn them off.
>
>Christopher James Huff <cja### [at] earthlinknet>
>http://home.earthlink.net/~cjameshuff/
>POV-Ray TAG: chr### [at] tagpovrayorg
>http://tag.povray.org/
>

Thanks for the info, I didn't know you could turn them off till you and
Gilles Tran told me. What I did was get rid of the light and use "finish
{ambient 1}."

Tomorrow (well, later today, but after I get some sleep) I'll post more and
give you guys a better clue to what this is all about.

--normdoering

Post a reply to this message