"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; obviously some kind of
> arcane syntax problem at my end that I haven't yet solved]

I know there's the thing with the forward/backward slashes in paths...

> As far as I can tell, the intention of your code is to take a *pre-rendered*
> image and find the brightest pixels => 1.0 (or more specifically, which color
> component goes over that limit.) The three functions...
>            #declare f_red = function {max(Pattern2 (x, y, z).red, 1)-1}
>                         etc.
> .......look like they expect to see values *over* 1.0, and to give the result as
> the additional amount.

Right-o.  Anything with a component over 1 is the only part that would show up.

> Unfortunately, what I see is a totally black render when I plug in a typical LDR
> image. That's to be expected, though-- unless I'm wrong about your intention--
> since an already-rendered LDR image has all of its pixels at or below 1.0, as
> the image file (and monitor) can only reproduce colors in the 0-1 range.

Hmmm.   I thought POV-Ray could write color values to a file that were over 1.
I certainly know from all my reading and poking around in the source code and
working with the gamma and color values that the industry algorithms have sanity
checks for values over 1...

> (Maybe you had HDR images in mind instead?)
>
> I re-worked a few things in the code to get your intended(?) result (re: using a
> pre-rendered LDR image), and it works quite nicely: Pixels *approaching* 1.0 are
> picked out. Cool!

Define a multiplier for the function right before the 1 is subtracted.
I faked an HDR image by using >1 on the blue channel.  Take your multiplier and
use a variable so you don't have to change all 3 when you want to tweak it.

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

Is there a way to render it as "HDR" and without any antialiasing first, and
then re-render /post-process it WITH aa?
Maybe along the lines of what I'm doing here, or an image convolution kernel or
something.


#declare M = 0.9999;
> #declare f_red = function {max(Pattern2 (x, y, z).red, 1)*M - 1}
> #declare f_grn = function {max(Pattern2 (x, y, z).green, 1)*M - 1}
> #declare f_blu = function {max(Pattern2 (x, y, z).blue, 1)*M - 1}


> // 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 - the fractional component.
It seemed to work that way for me with my version, but it was a last-minute
late-night hack, so maybe I double-reversed something....

Set M to 1.1 and see what happens... 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.
Use the *M version that I posted an the original color map, and all should be
well.

Post a reply to this message