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

"normdoering" <nor### [at] yahoocom> wrote in message
news:web.3dcf7587da80818e1dffbb4f0@news.povray.org...
>
> 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.

You can't. The only thing available is image_width and image_height and
you'd still need to enter those as the resolution being used for your output
image file. Using INI or the command line if you repeat the same size might
be okay, but same problem if you must type those in for each different input
image.
--
Farewell,
Bob

Post a reply to this message

hughes, b. wrote:
>"normdoering" <nor### [at] yahoocom> wrote in message
>news:web.3dcf7587da80818e1dffbb4f0[at]news.povray.org...
>>
>> 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.
>
>You can't. The only thing available is image_width and image_height and
>you'd still need to enter those as the resolution being used for your output
>image file. Using INI or the command line if you repeat the same size might
>be okay, but same problem if you must type those in for each different input
>image.
>--
>Farewell,
>Bob
>
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.


normdoering

Post a reply to this message

"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