"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > [Btw, I couldn't get my own version of your
> >       #declare Filename = ... file path ...
> > to work in Windows, despite multiple tries and guesses...]
>
> I know there's the thing with the forward/backward slashes in paths...

I finally got it to work (which is a major accomplishment for me, ha):
using DOUBLE backward slashes in Windows-- which is actualy mentioned in the
docs...
#declare Filename =
"C:\\Users\\Computer\\Documents\\Kens new POV-Ray scenes\\A1.png"

Double FORWARD slashes work too.

>
> Hmmm. I thought POV-Ray could write color values to a file that were over 1.

As far as *I* know (which isn't saying a lot), typical LDR image files like JPEG
and PNG top out at 255/255. Which makes sense, as to their final presentation on
a typical monitor.

> > But trying to determine which pixels are too bright *while* rendering
> > involves POV-ray's inner workings; as William alluded to, the scene's
> > pixel values (*prior* to being written to a file or to the preview screen)
> > can easily exceed 1.0... hence the 'failed AA' effect, for example. I guess
> > that they are clipped to that maximum only when the file is written, or
> > when the preview can't reproduce them as-is.

I've been rolling that seeming caveat around in my head since I posted it-- and
I now think I'm wrong: Once the too-bright pixels ARE eventually clipped to 1.0
maximum for the image file (and/or preview), the end result is just fine for
post-processing with the re-worked code here-- to find the brightest pixels. I
can't visualize any difference between that, and doing the same thing
'internally' in POV-ray like I initially imagined. The only difference I see is
that the code picks out pixels *at* 1.0 brightness, rather than > 1.0. But that
doesn't seem to be a deal-breaker, as to the code's intended use. As I reflect
more on the subtleties, I may turn out to be mistaken-- but the code seems to do
exactly what I envisioned... albeit *as* a post-processing step. But that's not
too painful a compromise ;-)

> > // I reversed the color order here, to get a 'positive' image,
> > // so the brightest pixels show up white instead of black
> >   [ 0 rgb 1 ]
> >   [ 1 rgb 0 ]
> >  }
> > }
>
> Odd, since the result of the function should provide 0 for LDR images,
> and white for anything over 1... oh, I see now.
> When you use your subtraction method inside the function, your max is now less
> than 1.  Then you subtract 1 and get a _negative_ value. That dips into the
> color map from the top, not the bottom, which is why you get backwards
> results...

Ha, I'm glad you figured that out; for me, it was just mucking around with
things until I got what looked like a good result! :-O

> Use the *M version that I posted an the original color map, and all should be
> well.

I'll give that a try.

BTW, I noticed something about my image results that makes me wonder about how
the max(...) function operates on other *functions*...

#declare OverOne = function{max(f_red (x,y,z), f_grn (x,y,z), f_blu (x,y,z))}

It seems that if every entry in max(...) is actually EQUAL, the overall function
returns all THREE values (combined? added?), not just one. I'm out of my depth
here, though; maybe that's how max always treats equal values(?), even if
they're just floats. But that's not a problem with the *code's* use; it works as
planned.

I've attached an image to illustrate this.

Post a reply to this message

Attachments:
Download 'max_result_with_functions.jpg' (93 KB)

Preview of image 'max_result_with_functions.jpg'