"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