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

> > 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.

Yes - this was bouncing around in my head today, in the insufficiently
caffeinated fog of fatigue, and I think you'd have to define a special
antialiasing mode to use something like my functions in the antialiasing
convolution matrix.
http://cs.trinity.edu/~jhowland/class.files.cs357.html/pov-new/Docs/pov155.htm

I quickly skimmed over some aa/convolution websites, and using a 7x7 matrix with
jittering seemed to give very nice results.

> 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.

Yes.  Because OverOne is a function that acts more like a flag - because you
wanted to look at pixels with ANY component of the rgb color vector over one.

I have a mantra that I repeat to myself: "FUNCTIONS RETURN SCALAR VALUES".

So max returns the maximum value of all the arguments it is given.
1 is 1 is 1 is 1 is 1.
Or as Ayn Rand would admonish, "A is A."

So, if ANY one of the three components triggers the "bright pixel switch", the
value of its component function returns 1.  So OverOne acts as a sort of Boolean
indicator to show which pixels have at least one_component satisfying your
criteria.

So interpreting your visual results logically,
Are there pixels in the red channel that are > M?  Yes.
Are there pixels in the grn channel that are > M?  Yes.
Are there pixels in the blu channel that are > M?  Yes.

Which of those pixels meet your criteria?  ALL of them.

So OverOne shows ALL of those channels.  Because they way you wrote your inquiry
was to detect those brighter pixels.  And AFAIK, POV-Ray's aa mechanism doesn't
function through individual color channels, it just interpolates the whole rgb
color vector.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > It seems that if every entry in max(...) is actually EQUAL, the overall
> > function returns all THREE values (combined? added?), not just one.

> Yes.  Because OverOne is a function that acts more like a flag - because you
> wanted to look at pixels with ANY component of the rgb color vector over one.
> [snip]

Clear and concise; thanks a bunch. The docs for max(...) don't touch on any of
this, although I guess it's 2nd-nature knowledge to programmers. Parts of your
explanation should be included there, in my humble opinion...for poor folks like
me.

BTW, there are seemingly simple and straightforward parts of your code that
fascinate me... because I would not have expected them to work:
[using my own example...]

#declare Filename =
"C:\\Users\\Computer\\Documents\\Kens new POV-Ray scenes\\A1.png"

then yours...
#declare ImageMap = pigment {image_map {Filename}}

I've actually never done this kind of thing before(!)-- mainly because I
couldn't get the initial file path syntax to work until now. But I digress...
In essence,
          Filename =
               "A1.png" -- or maybe just  A1.png  with no quotes ?

One is an 'image string' (which is understandable as a #declared string), the
other is just... naked. In any case,
            #declare ImageMap = pigment {image_map {Filename}}
looks like it would end up as
            #declare ImageMap = pigment {image_map {"A1.png"}}
or just
            #declare ImageMap = pigment {image_map {A1.png}}

.... neither with the usually-required prefix   png "A1.png", although AFAIU,
maybe the prefix isn't absolutely required anyway.

Yet it works. I suspect that at least the double-quote version of A1.png is
correctly being recognized, although I'm not sure as to where the double quotes
arise from. Is it because the entire file-path name is itself in double quotes?

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Yet it works. I suspect that at least the double-quote version of A1.png is
> correctly being recognized, although I'm not sure as to where the double quotes
> arise from. Is it because the entire file-path name is itself in double quotes?

It's because the variable Filename is declared with a string value, so using
Filename is just like using that same string value as the image map filename
parameter - they are equivalent to the SDL parser.

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> ...I'm not sure as to where the double quotes
> > arise from. Is it because the entire file-path name is itself in
> > double quotes?
>
> It's because the variable Filename is declared with a string value, so using
> Filename is just like using that same string value as the image map filename
> parameter - they are equivalent to the SDL parser.

Thanks. Sometimes, I probably think too literally about this kind of stuff (out
of ignorance)-- when the parser already 'knows' what to do.

Btw, the OverOne function in the re-worked code should probably be re-named as
          AtOne  or  LimitOne

to more accurately describe its changed result ;-)

Post a reply to this message

On 2021-02-11 7:56 PM (-4), Cousin Ricky wrote:
> 

> trade-off between good hyper-white effects and good anti-aliasing, and
> on balance, I'd have to say I prefer the latter.

*former

Post a reply to this message