"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

On 2/26/23 12:32, Kenneth wrote:
> There is something about the REC 709 standard that has confused me for quite
> awhile, in a general way. (I'm probably going off-topic here). AFAIU, it is a
> standard for video capture and display, so I'm not sure that I understand how it
> relates to color -> grayscale conversion within your povr branch (as for
> height_field use.)

Sure I'm not the one to answer your questions in any definitive way, but...

Firstly, I focused on the color to greyscale / luminosity / height 
conversion while looking at the standards for my supported povr 
conversions. Further, I had a head start in that Christoph had dug some 
into these already the some of the new conversions already existed in 
the code for image input and output, if not the in code greyscale 
conversion itself. He and others had talked about 709 being a better 
color to grey for v3.8 defaults in the newsgroups.

---

That said. I think the difference being talked about in the 709 vs 
'709-R' is likely the fact most LCD based displays cannot reach the 
extremes for darkness and brightness and this is probably what the 
'709-R' you see is about. This I think more true of darkness - lcd 
displays simply fail for dark values because ultimately you need to turn 
off each pixel for true black.

While I am NOT an expert at animation encoding tools, I do not think you 
will see much if any real difference in what gets displayed between 709 
and 709-R. The reality is when when code a black value of 0.0 in a still 
image or animation frame, we mostly do NOT get a 0 pixel value, but 
something brighter.

So... What I suspect is encoding to an animation with '709-R' will 
compress better because fewer overall values are being represented. In 
other words the 'R' is a compression which accepts the typical reality 
of today's displays while pure 709 is optimistic that some few folks 
have displays that can actually do something closer to the extremes.

On the bright side (of displays), I'm less sure 'R' is the reality as I 
think some display can get quite bright (true too cheap ones can be 
dim). Some newer LCD displays at least can occasionally go completely 
dark by region, if not by pixel. There are fancy and pricey displays out 
there too, but most don't have them.

So! All this mostly me guessing - there is probably wiki/web info out 
there, but I didn't read up on anything on answering here.

If someone really knows better - feel free to jump in and correct as 
need be.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/26/23 12:32, Kenneth wrote:
> > There is something about the REC 709 standard that has confused me for quite
> > awhile, in a general way. (I'm probably going off-topic here). AFAIU, it is a
> > standard for video capture and display, so I'm not sure that I understand
> > how it relates to color -> grayscale conversion within your povr branch (as
> > for height_field use.)
>
> Sure I'm not the one to answer your questions in any definitive way, but...
>

Your comments are actually quite helpful and informative, thanks!

I probably should have qualified my earlier statement about seeing different
animation results re: using 'plain' REC 709 vs. 709-R:
It seems to depend on which video app I use to play-back the finished video.
IIRC!

I have not done a definitive series of tests lately. Once I saw that 709-R
'looked' better and matched my POV-ray image render previews within POV-ray, I
stuck with it. This is yet another of those situations where I got side-tracked
from working on a scene, and didn't pursue the problem as far as I would have
liked to.

I could probably spend 23 1/2 hrs per day just doing detailed and pedantic tests
of one kind or another! (Lately, it seems that I am, ha.)
-----

BTW, I am *still* chasing-down that height_field 'mirror reversal' thing when
using functions. Just today, I discovered yet another little interesting
behavioral quirk. I will probably post it in the earlier/recent thread about
"functions to height_fields", as it seems more appropriate there.

Post a reply to this message