"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Because it's hiding under you nose - under the hood.
> > It the image_map "function" that is all shoved into ... one pigment pattern.
> > [snip]
> > So how does a function work?
> > We take <x, y, z> and plug those into the function, which computes a color
> > value.
> >
> > But you could also pre-calculate the color values, and store them - in a
> > file-- to reference when you're looping through all of the position values -
> > and that's called an image file.  That gets implemented via the pigment
> > {image_map} syntax.
>
> Yeah, I guess that my 'dream scheme' of...
>      trace --> eval_pigment --> a SINGLE function{pigment...} [somehow?]
> ....is kind of an attempt to mimic what goes on 'under the hood'... a sort of
> 'reverse engineering' scheme, devised in SDL.

But what you're essentially doing is exactly that.  Because there is no
"function" - it's a look-up table - reading in the color values for each x,y
pixel in the image.   It's simply the fact that it's done under the hood, via
compiled source code, that makes it seem "different".

povray-3.7-stable/povray-3.7-stable/source/backend/support/imageutil.cpp

bool image_map(const VECTOR EPoint, const PIGMENT *Pigment, Colour& colour)
{
 int reg_number;
 DBL xcoor = 0.0, ycoor = 0.0;

 // If outside map coverage area, return clear

 if(map_pos(EPoint, ((const TPATTERN *) Pigment), &xcoor, &ycoor))
 {
  colour = Colour(1.0, 1.0, 1.0, 0.0, 1.0);
  return false;
 }
 else
  image_colour_at(Pigment->Vals.image, xcoor, ycoor, colour, &reg_number,
false);

 return true;
}

"If the x,y position is outside of the image area, return a clear value, else
return the color of the image at that x,y value."
No function.   Just an algorithm in a loop.

> The seemingly effortless way that POV-ray itself can take an image_map and turn
> it into a single function{pigment...}-- with all of the original pixels in the
> correct order-- is like Black Magic to me.

Why?  Can we even count the number of software packages that can do that?
What about a movie player that can read them in fast enough to give you greater
than 15 fps?

> Yeah, those little caveats did occur to me. :-[
> I agree: My hoped-for scheme seems to be not-so-elegant after all. Compared to
> that, my older scheme of...
>        trace --> eval_pigment --> 480,000 colored boxes
> .... suddenly looks like an elegant and simple stroke of genius! :-P

I've done that kind of the opposite way - tracing objects, and converting the
height to a color value, but I realized it was just as easy to do with a
gradient pigment pattern...

Now, what I have wanted, and suggested in the past, is for there to be a
mechanism by which the compiled source code stores all the color data for an
image file in an SDL-accessible 2D array.   Which would kinda give you what you
want without all of the mucking around.

> > So how does one take 48,000 boxes and color them all with one function?
> >
> > union {
> > .... all your boxes ...
> > pigment {image_map}
> > }
> >
> Yes, very straightforward-- once my single and way-too-elaborate function itself
> is created! But I guess I need to discard my eval_pigment idea itself as
> unworkable (i.e., initially evaluating every *individual* pixel of an input
> image, to ultimately create some sort of single function to represent all the
> colors and pixel positions.)

what about function {pigment {image_map}}  ?

And I guess I should point out that _form_ follows _function_.
What do you want to do with the function once you've got it, that you need to
have it in function form?

Post a reply to this message