On 4/16/2012 7:26 AM, D103 wrote:
>  From there, it's a simple thing to determine if the point in question is water,
> or if not, how close to water it is. If the planet in use has no surface water,
> then it would be a simple thing to add an "eval_pigment" to the macro, with a
> conditional value which returns true or false depending, thus saving
> computational time. :)

Tip: when doing a lot of eval_pigment tests, *do not* include 
functions.inc. Just copy the macro to your scene file. Parsing will be a 
/lot/ faster. This is true for all POV-Ray macros.

Also, if you can somehow use functions instead of 2D arrays, do it. 
Storing images as 2D arrays in POV is extremely inefficient.

If you need help with the water proximity detection, I've got a blur 
macro that may be of some use.

Happy Raytracing,

Sam

Post a reply to this message

> Alain<aze### [at] qwertyorg>  wrote:

>>> ..........................
>>> (I know there's one around
>>> somewhere, can't find it at the moment).
>>> ..........................
>
>>
>>    From the documentations:
>>
>> As of version 3.7 experimental support for reading the pixel resolution
>> of an image map was added. This is done by giving an image map pigment
>> identifier to max_extent(), which will then return the resolution of the
>> image map as the x and y values of the returned vector.
>>
>> Sample code:
>> #declare Image =
>> pigment {
>>     image_map {
>>       jpeg "YourImage.jpg"
>>       once
>>       }
>>     };
>>
>> #declare Resolution = max_extent ( Image );
>>
>> It return Resolution =<horizontal_size, vertical_size, 0>;
>>
>>
>>
>> Alain
>
> That was indeed it. *feels embarrassed* :(
>
> Thanks Alain, I didn't realise (not having actually used it ;) ) that
> max_extent() returned a vector. This makes things a little easier.
>
> Regards
> D103
>
>
>
>
max_extent() and min_extent() both return vectors. It's needed to define 
the bouncing box of the object used as an argument.
In ordinary use, min_extent return the front or near, bottom left corner 
of the bounding box and max_extent() return the back or far, top right 
corner.

Post a reply to this message

Le 20/04/2012 04:34, Alain a écrit :
>>>
>>> As of version 3.7 experimental support for reading the pixel resolution
>>> of an image map was added. This is done by giving an image map pigment
>>> identifier to max_extent(), which will then return the resolution of the
>>> image map as the x and y values of the returned vector.
>>>
>>> Sample code:
>>> #declare Image =
>>> pigment {
>>>     image_map {
>>>       jpeg "YourImage.jpg"
>>>       once
>>>       }
>>>     };
>>>
>>> #declare Resolution = max_extent ( Image );
>>>
>>> It return Resolution =<horizontal_size, vertical_size, 0>;
>>>
>>>

> max_extent() and min_extent() both return vectors. It's needed to define
> the bouncing box of the object used as an argument.
> In ordinary use, min_extent return the front or near, bottom left corner
> of the bounding box and max_extent() return the back or far, top right
> corner.

Indeed, I found the overloading a bit too much. Can't it be keep clear
and meaningful instead of a kludge on max_extend ?
what about

#declare Resolution = image_size ( Image );

instead ?
With neat specification about a 3D vector: width in pixel, height in
pixel, depth in bits or bit per channel ?
Maybe more than 3D vector ? 3rd one for the number of channels and 4th
one for the depth in bit per channel ?
What about alpha... 5D ?

Note: I'm talking about the SDL itself, I find perturbing reusing
max_extend in such context. I like dog called dog, and cat a cat.


If we go down to image analysis in SDL, are we not sacrificing some
concepts of Povray to make a clone of photoshop/gimp ?

-- 
Real software engineers work from 9 to 5, because that is
the way the job is described in the formal spec.  Working
late would feel like using an undocumented external procedure.

Post a reply to this message

Le 2012/04/20 03:02, Le_Forgeron a écrit :
> Le 20/04/2012 04:34, Alain a écrit :
>>>>
>>>> As of version 3.7 experimental support for reading the pixel resolution
>>>> of an image map was added. This is done by giving an image map pigment
>>>> identifier to max_extent(), which will then return the resolution of the
>>>> image map as the x and y values of the returned vector.
>>>>
>>>> Sample code:
>>>> #declare Image =
>>>> pigment {
>>>>      image_map {
>>>>        jpeg "YourImage.jpg"
>>>>        once
>>>>        }
>>>>      };
>>>>
>>>> #declare Resolution = max_extent ( Image );
>>>>
>>>> It return Resolution =<horizontal_size, vertical_size, 0>;
>>>>
>>>>
>
>> max_extent() and min_extent() both return vectors. It's needed to define
>> the bouncing box of the object used as an argument.
>> In ordinary use, min_extent return the front or near, bottom left corner
>> of the bounding box and max_extent() return the back or far, top right
>> corner.
>
> Indeed, I found the overloading a bit too much. Can't it be keep clear
> and meaningful instead of a kludge on max_extend ?
> what about
>
> #declare Resolution = image_size ( Image );
>
> instead ?
> With neat specification about a 3D vector: width in pixel, height in
> pixel, depth in bits or bit per channel ?
> Maybe more than 3D vector ? 3rd one for the number of channels and 4th
> one for the depth in bit per channel ?
> What about alpha... 5D ?
>
> Note: I'm talking about the SDL itself, I find perturbing reusing
> max_extend in such context. I like dog called dog, and cat a cat.
>
>
> If we go down to image analysis in SDL, are we not sacrificing some
> concepts of Povray to make a clone of photoshop/gimp ?
>

As the documentation, that I copyed verbatim, state, it's still in the 
experimental stage. Experimental features are inherently subject to changes.

Post a reply to this message

Thanks very largely to the help I have received here (and thank you all _very_
much for it), I have got stage one of the simulation into developement. The sim
can be fed large scale images and convert them into a text file filled with
numbers.

Somewhere however, there is a bug in the coding which causes all the numbers in
the generated file to be the same. :(

Following is the snippet with all the relevant code. (Is code the right word?)

/*Image Import/Export
Section--------------------------------------------------------------------*/

//eval_pigment copied from "functions.inc" to reduce parse overhead time

#macro eval_pigment(pigm, vec)
    #local fn = function { pigment { pigm } }
    #local result = (fn(vec.x, vec.y, vec.z));
    result
#end

#declare ColImg = pigment {
  image_map {
    jpeg ".jpg"//image name deleted for security ;)
  }
}

#declare ImgTraceObj = plane {
  -z, 0
  pigment {
    ColImg
  }
}

#declare Res = max_extent(ColImg);

#debug concat("Resolution of image is ", vstr(2, Res, ",", 0, 0), ".\n")

#fopen TmpImg "ImgColArray.txt" write

#declare Xres = Res.x;
#declare Yres = Res.y;

#declare XCount = 0;

#write(TmpImg, "array[", Xres, "] [", Yres, "] {\n")

#while(XCount<Xres)
  #declare YCount = 0;
  #write(TmpImg, "  {")
  #while(YCount<Yres)
    #declare TmpCol = eval_pigment(ColImg, <XCount, YCount, 0>);
    #write(TmpImg, " ", vstr(3, TmpCol, ",", 0, 5), ", ")
    #declare YCount=YCount+1;
  #end
  #write(TmpImg, " }\n")
  #declare XCount=XCount+1;
#end

#write(TmpImg, "}")

/*-----------------------------------------------------------------------------------------------*/

I haven't had time to go through it and debug & search the docs myself, I
finished it in a hurry, and on top of that, I'm getting ready for return to
studies, as well as possibly starting a new job. :(

Regards
D103

Post a reply to this message

> Thanks very largely to the help I have received here (and thank you all _very_
> much for it), I have got stage one of the simulation into developement. The sim
> can be fed large scale images and convert them into a text file filled with
> numbers.
>
> Somewhere however, there is a bug in the coding which causes all the numbers in
> the generated file to be the same. :(
>
> Following is the snippet with all the relevant code. (Is code the right word?)
>
> I haven't had time to go through it and debug&  search the docs myself, I
> finished it in a hurry, and on top of that, I'm getting ready for return to
> studies, as well as possibly starting a new job. :(
>
> Regards
> D103
>
>

Your problem is that your image is still mapped from <0,0> to <1,1> and 
tilled to cover the whole plane.
As you iterate through your loop, you effectively sample the exact same 
point of your image every time.
If you add the "once" keyword, then all results would be zeros except 
for one.

2 possibilities:
1 - Scale your image and scan it in unit increments. Sample:
#declare ImgTraceObj = plane {
   -z, 0
   pigment {
     ColImg scale<Xres, Yres,1>
   }
}
OR
#declare ImgTraceObj = plane {
   -z, 0
   pigment {
     ColImg
   }
scale<Xres, Yres,1>}

As it's a plane (an infinite object) passing through the origin (point 
<0,0,0>), there is no differences between the two cases.

2 - Keep the image unchanged, but scan it in 1/Xres and 1/Yres increments.
Sample:
#declare TmpCol = eval_pigment(ColImg, <XCount/Xres, YCount/Yres, 0>);

For large images, this can introduce some location errors due to 
floating point rounding and presision errors.



Alain

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
>
> Your problem is that your image is still mapped from <0,0> to <1,1> and
> tilled to cover the whole plane.
> As you iterate through your loop, you effectively sample the exact same
> point of your image every time.
> If you add the "once" keyword, then all results would be zeros except
> for one.
>
> 2 possibilities:
> 1 - Scale your image and scan it in unit increments. Sample:
> #declare ImgTraceObj = plane {
>    -z, 0
>    pigment {
>      ColImg scale<Xres, Yres,1>
>    }
> }
> OR
> #declare ImgTraceObj = plane {
>    -z, 0
>    pigment {
>      ColImg
>    }
> scale<Xres, Yres,1>}
>
> As it's a plane (an infinite object) passing through the origin (point
> <0,0,0>), there is no differences between the two cases.
>
> 2 - Keep the image unchanged, but scan it in 1/Xres and 1/Yres increments.
> Sample:
> #declare TmpCol = eval_pigment(ColImg, <XCount/Xres, YCount/Yres, 0>);
>
> For large images, this can introduce some location errors due to
> floating point rounding and presision errors.
>
>
>
> Alain

Ok, thanks very much. :) I think I'll use the scale pigment, floating point
precision errors are not what I need.

Regards,
D103

Post a reply to this message

"D103" <nomail@nomail> wrote:
> Ok, thanks very much. :) I think I'll use the scale pigment, floating point
> precision errors are not what I need.
>
> Regards,
> D103

Just realised that that would require two declarations of the image. What size
image would cause fp errors? Current images used are at the most 4096x2048.

Regards
D103

Post a reply to this message

> "D103"<nomail@nomail>  wrote:
>> Ok, thanks very much. :) I think I'll use the scale pigment, floating point
>> precision errors are not what I need.
>>
>> Regards,
>> D103
>
> Just realised that that would require two declarations of the image. What size
> image would cause fp errors? Current images used are at the most 4096x2048.
>
> Regards
> D103
>
>
>

Thinking about it further, you don't even need to apply the image to an 
object.

#declare ColImg=  pigment{ image_map {jpeg "my_image.jpg"}}
#declare Res = max_extent(ColImg);

You can now scale the pigment directly:
#declare ColImg = pigment{ ColImg scale<Res.x, Rex,y,1>}
This scales the pigment and reattribute it to the same identifier.

Then, you use eval_pigment directly on the pigment identifier.

It depends...
4096 and 2048 are exact powers of 2, and should not cause any error, or 
negilgible ones.
4000 x 3000 WILL cause fp errors.
800 x 600 will also cause fp errors as those values are not powers of 2.

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:
>
> Thinking about it further, you don't even need to apply the image to an
> object.
>
> #declare ColImg=  pigment{ image_map {jpeg "my_image.jpg"}}
> #declare Res = max_extent(ColImg);
>
> You can now scale the pigment directly:
> #declare ColImg = pigment{ ColImg scale<Res.x, Rex,y,1>}
> This scales the pigment and reattribute it to the same identifier.
>
> Then, you use eval_pigment directly on the pigment identifier.
>
> It depends...
> 4096 and 2048 are exact powers of 2, and should not cause any error, or
> negilgible ones.
> 4000 x 3000 WILL cause fp errors.
> 800 x 600 will also cause fp errors as those values are not powers of 2.

Will begin testing that, thanks. :)

Regarding the images, AFAIK all are powers of two, something to do with the game
engine IIRC, so that should be fine then. :)

Regards,
D103

Post a reply to this message