"Leroy" <whe### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> I found a big difference in using a image pigment in the height_field function
> and that pigment in the height_field alone.
>

Lets try attaching that picture again
I also need to state the the function height_field is revered left to right so
the difference can be noticed better

Post a reply to this message

Attachments:
Download 'difference.jpg' (60 KB)

Preview of image 'difference.jpg'

"Leroy" <whe### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> I found a big difference in using a image pigment in the height_field function
> and that pigment in the height_field alone.
>
> that is
>  #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}
>  #declare Dirt =
> function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}
>  height_field {function 400,400{ Dirt(x,y) }...
> and
>
>  height_field {tga "FinalB.tga"
>
> they don't match! The function has a lower height and seems to be shifted both
> in the +z and +x directions
>

Out of curiosity, I used your code examples but with my own .png image_map (not
..tga), and I see some interesting things:

First, I was surprised that your constructed DIRT function works at all. Z's
instead of y's there? But it does work! Substituting y for z *also* works:
       function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}

But moving on...
My test image_map includes 3 primary colors, plus a linear white-to-black ramp.
The resulting height_fields have a gradient-y color_map applied, from black to
reddish. (I shouldn't have used black; it makes the results difficult to see.)

I don't see any x or z reversal between the two HF examples. We're both using
the (1-z) trick for the function version, so that should solve it. It does for
me.

But *most* interestingly, the two HF-creation methods show some different
results for the height values. The 'direct' approach uses only the RED color
channel, AND shows the linear white-to-black 'ramp' correctly; the function
approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
that!

Post a reply to this message

Attachments:
Download 'height_field_direct_and_by_functions_kw.jpg' (266 KB)

Preview of image 'height_field_direct_and_by_functions_kw.jpg'

"Kenneth" <kdw### [at] gmailcom> wrote:

> Out of curiosity, I used your code examples but with my own .png image_map (not
> ..tga), and I see some interesting things:
>
> First, I was surprised that your constructed DIRT function works at all. Z's
> instead of y's there? But it does work! Substituting y for z *also* works:
>        function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}

You can of course put anything you want in those "slots".   It's a function.
When you render an image and you are evaluating a pigment pattern, then you have
the ability to sample the x, y, and z values at the place where the ray-object
intersection takes place.  But there sure isn't a requirement to invoke any
function in that order, or even using those values at all.
Using z instead of y just switches the plane in which that function is
evaluated.

> But moving on...
> My test image_map includes 3 primary colors, plus a linear white-to-black ramp.
> The resulting height_fields have a gradient-y color_map applied, from black to
> reddish. (I shouldn't have used black; it makes the results difficult to see.)
>
> I don't see any x or z reversal between the two HF examples. We're both using
> the (1-z) trick for the function version, so that should solve it. It does for
> me.
>
> But *most* interestingly, the two HF-creation methods show some different
> results for the height values. The 'direct' approach uses only the RED color
> channel, AND shows the linear white-to-black 'ramp' correctly; the function
> approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
> bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
> that!

I'd like to see if the function approach using the red channel gives the same
result as either of these experiments.

Also, you should look into all of the input_gamma for gamma pre-corrected file
formats stuff, to see if that's what's going on.   Maybe if the image file gets
loaded with an input gamma specifying 1.0 or 2.2 (srgb) then they will be the
same.   Just to check that it's the heightfied creation method vs the image
input method that supplies the data to the heighfield.

- BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > But *most* interestingly, the two HF-creation methods show some different
> > results for the height values. The 'direct' approach uses only the RED color
> > channel, AND shows the linear white-to-black 'ramp' correctly; the function
> > approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
> > bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
> > that!
>
> I'd like to see if the function approach using the red channel gives the same
> result as either of these experiments.

Using Leroy's function and changing his .blue to .red, I still see the
'gamma-curving' ramp in the HF. Same with .green.
>
> Also, you should look into all of the input_gamma for gamma pre-corrected file
> formats stuff, to see if that's what's going on...

An interesting point-- and a good suggestion. By using the newer(?) 'gamma'
value keyword with my .png test image, it eliminates the gamma-curve effect seen
with the function method; the HF ramp is nice and linear now:

#declare PigM =
function{pigment{image_map{png "MY_IMAGE.png" gamma 1.0 }}}

Yet when the image_map is used 'directly' to create the HF (no pre-function
stuff), it works linearly as expected, without any gamma fiddling.

I don't know if this unexpected difference is mentioned in the docs; I haven't
seen anything that expressly mentions it.

-------
By the way, I was a *little* bit mistaken about the 'direct' image-to-HF method
using only the RED channel. With a different color_map and lighting, I see a
*tiny* amount of the GREEN channel used as well, but it looks almost
non-existent. See the attached render.

Post a reply to this message

Attachments:
Download 'test_hf_red_and_green_channels.jpg' (70 KB)

Preview of image 'test_hf_red_and_green_channels.jpg'

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > First, I was surprised that your constructed DIRT function works at all. Z's
> > instead of y's there? But it does work! Substituting y for z *also* works:
> >        function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}
>
> You can of course put anything you want in those "slots".   It's a function.
> When you render an image and you are evaluating a pigment pattern, then you
> have the ability to sample the x, y, and z values at the place where the
> ray-object intersection takes place.  But there sure isn't a requirement
> to invoke any function in that order, or even using those values at all.
> Using z instead of y just switches the plane in which that function is
> evaluated.
>

But in the case of a function from a (flat) image_map, isn't the 'plane' just
x/y?

My understanding (from the docs) is that a function takes only a 'slice' of a
pattern in the x/y plane, by definition. Granted that most patterns are 3-D and
that even an image_map extends infinitely into z, I thought that the function
would need x and y (not z) as its arguments because of that 'slice'. In other
words, z is usually not used at all (and/or has no real meaning for a flat
image_map.) But since Leroy's function works as-is and uses z... there is
obviously still something fundamental that I'm not grasping about function
arguments and what they mean.

:-[

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

>
> My understanding (from the docs) is that a function takes only a 'slice' of a
> pattern in the x/y plane, by definition...

....for use in a height_field, that is! Sorry if I didn't make that clear.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> >
> > My understanding (from the docs) is that a function takes only a 'slice' of a
> > pattern in the x/y plane, by definition...
>
> ....for use in a height_field, that is! Sorry if I didn't make that clear.

 #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}

 #declare Dirt =
function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}

 height_field {function 400,400{ Dirt(x,y) }...


I think maybe what's going on there is much like passing values into a macro
using macro arguments.

he's passing (x, y) into Dirt () when he invokes it through the hf declaration.
and so Dirt sees 2 values, and assigns them to (x, z) in its definition.

Confusing, and needs checking to verify, but that's my take at 6:30am.  ;)

- BW

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Also, you should look into all of the input_gamma for gamma pre-corrected file
> > formats stuff, to see if that's what's going on...
>
> An interesting point-- and a good suggestion. By using the newer(?) 'gamma'
> value keyword with my .png test image, it eliminates the gamma-curve
> effect seen with the function method; the HF ramp is nice and linear now:

(actually, the ability to gamma-correct the image goes all the way back to at
least v3.7.0)
>
> #declare PigM =
> function{pigment{image_map{png "MY_IMAGE.png" gamma 1.0 }}}
>
> Yet when the image_map is used 'directly' to create the HF (no pre-function
> stuff), it works linearly as expected, without any gamma fiddling.

I also tested v3.7.0, and the difference is there as well. It's strange that I
never noticed this until now; I've been running image_map functions as
height_fields for years! I guess that having a linear white-to-black ramp in the
image as a tester is something I never used(?). Or I just wasn't paying enough
attention...
>
> I don't know if this unexpected difference is mentioned in the docs; I haven't
> seen anything that expressly mentions it.
>

It IS there; I had to search for it in the 3.8 documentation (the additional
emphasis is mine):

2.3.4.6 GAMMA IN INPUT IMAGES--
"Normally, gamma handling of input image files will work fine without
intervention, but in some cases it may *fail.* To resolve such problems, the
default handling can be overridden using the gamma keyword..."

"When using an image file in a *height_field*, bump_map or image_pattern,
POV-Ray will convert the image data to linear values *if* you explicitly specify
a gamma for that particular file; if you don't, no gamma adjustment will be
performed..."

Since my test image was made at the usual 2.2 (or perhaps sRGB) gamma-- as was
Leroy's presumably-- this makes sense.

Although, it does not really explain the gamma difference between a
function{pigment{...image_map...}} vs. a direct  height_field{...image_map...}

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> Although, it does not really explain the gamma difference between a
> function{pigment{...image_map...}} vs. a direct  height_field{...image_map...}

Well, I mean this is what I'm saying - without knowing what the data flow is
under-the-hood in source code, we don't know what sorts of logic and switches
are being performed before the data finally gets to where we're directing it.
Or what bugs or omissions are lurking in there.

So, either a scene or three would have to get run through a debugger, or some
sort of clever scene and reference image would have to be used to see exactly
what is happening with any given set of keywords.

So, maybe write a macro that stacks a series of boxes whose height is determined
by a calculated grayscale value based off of a loop counter.  That way you get
your ramp, but it's unsullied by any sort of gamma handling or under-the-hood
interpretation whatsoever.  But probably a standard gradient or colormap/spline
would work.  The key is to have defined _heights_ to use as a reference for any
given .gray value.

Then you could render that as an image using an orthographic camera to get the
same grayscale values for your image (being careful to understand if any gamma
issues apply to saving the render image) and then that could be your reference
image for further experiments.

Then maybe use one of those gamma/srgb conversion macros we worked on a ways
back to manually simulate a given gamma value, and compare that a
function/heightfield using the reference image with an input gamma applied.

It also might be a good idea to poke through the source code and see how
everything works, and post relevant code snippets for reference / help
interpreting.

- BW

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Leroy" <whe### [at] gmailcom> wrote:
> > "Leroy" <whe### [at] gmailcom> wrote:
> > I found a big difference in using a image pigment in the height_field function
> > and that pigment in the height_field alone.
> >
> > that is
> >  #declare PigM=function{pigment{image_map{ tga "FinalB.tga"}}}
> >  #declare Dirt =
> > function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)}
> >  height_field {function 400,400{ Dirt(x,y) }...
> > and
> >
> >  height_field {tga "FinalB.tga"
> >
> > they don't match! The function has a lower height and seems to be shifted both
> > in the +z and +x directions
> >
>
> Out of curiosity, I used your code examples but with my own .png image_map (not
> ..tga), and I see some interesting things:
>
> First, I was surprised that your constructed DIRT function works at all. Z's
> instead of y's there? But it does work! Substituting y for z *also* works:
>        function(x,y){select(PigM(x,1-y,0).blue,0,0,PigM(x,1-y,0).blue)}
>
> But moving on...
> My test image_map includes 3 primary colors, plus a linear white-to-black ramp.
> The resulting height_fields have a gradient-y color_map applied, from black to
> reddish. (I shouldn't have used black; it makes the results difficult to see.)
>
> I don't see any x or z reversal between the two HF examples. We're both using
> the (1-z) trick for the function version, so that should solve it. It does for
> me.
>
> But *most* interestingly, the two HF-creation methods show some different
> results for the height values. The 'direct' approach uses only the RED color
> channel, AND shows the linear white-to-black 'ramp' correctly; the function
> approach uses only the BLUE channel...but shows an unexpected gamma-value(?)
> bending of the 'ramp' (and some other shapes there too.) I wasn't expecting
> that!

First, I like your image base documentation!

 function(x,z){select(PigM(x,1-z,0).blue,0,0,PigM(x,1-z,0).blue)} was made to
take care of some funky HF,s made with tga palette images. It seem that the HF
function produce negative value that showed up as spikes.
 function(x,z){PigM(x,1-z,0).hf} works for all of the other image formats I've
tried.( gif | jpeg | pgm | png | ppm | tga )

 Things I think I've learned:

 function(a,b) will work as long as those variables are used in the function.

 function(x,y,z){pigment{...} won't work

 height_field{will take function(x) I guess it sends 3 variables x,y,z float
types that have nothing to do with the x,y,z vectors.

The image_map goes on forever in the +z direction so
  function(x,z){PigM(x,1-z,.5).hf}
 still works, it might do so in the -z direction, I haven't tried it.

I'm still testing image formats. I've done at lease one test of these gif , jpeg
, pgm , png , ppm , tga(256 mapped, 24 bit compressed,24 bit NOT compressed)

I plan to do all the image formats that POV can Make and Read.

Have fun!

Post a reply to this message