I've been away from the newsgroups for awhile-- busy running lots of radiosity
tests (and fixing computer problems). Along the way, I noticed something about
the renders that has nothing to do with radiosity, but with antialiasing.

To put it a simple way: When image pixels go over <1,1,1> in brightness
(regardless of how), antialiasing starts to fail, both in the on-screen preview
and in the saved image file. There also appear to be problems with just 'pure'
colors like <1,0,0> when elevated to, say, <10,1,1>. I've included an image of
various experiments. It's not an effect that immediately begins past <1,1,1> but
comes in gradually. So far, I have not seen this effect mentioned in the
documentation. I don't think the failed AA is simply the result of a difference
in contrast/brightness with surrounding darker pixels.

[Currently, I'm running a POV-ray v3.8 development build in Windows, with the
newer AA Sampling_Method=3 and Stochastic_Seed; but I also tried the typical
method 2, with the same results. Perhaps there is a way to reduce or eliminate
the 'missing AA' with better settings?]

Of course, this lack of AA would probably not show up in most normally-lit
POV-ray scenes, where light_sources and object textures are 'balanced' correctly
and result in pixels that don't exceed <1,1,1>. (Otherwise, it would simply be
'bad lighting'.) But the lack of AA can be very obvious in pure radiosity
scenes, when a light-emitting object is visible -- like a bright lightbulb for
example, that needs its finish{emission} value increased for effect.

In more detail: Since antialiasing involves shooting many rays into a scene per
pixel (rather than just one ray), then averaging(?) them to get a smooth result,
it seems that the color/lighting computations for that pixel should be clamped
at a maximum of <1,1,1> *before* the averaging is done. I don't know the inner
workings of the antialiasing mechanism, so this is just my guess. For example,
when a white object's pixel brightness is created by, say, emission 10, it
should be automatically reduced to <1,1,1> before the AA 'averaging' scheme
kicks in-- since 'white is white', and a typical low-dynamic-range 24-bit image
can only reproduce pure white as <1,1,1> anyway, not <10,10,10>.

There *is* a simplistic way of correcting this in pure radiosity scenes-- at
least in certain circumstances-- by making two identical objects, one invisible
with the high required emission value, and one that's visible but with an
emission value of 1.0 (and a no_radiosity flag). But this scheme could get
cumbersome.

I don't know how antialiasing treats global lighting from a HDR image (like a
HDR skydome), where the emitting pixels in the image can be far brighter than
<1,1,1>. If those pixels are actually visible in the scene, or are reflected in
a scene's mirrored sphere, perhaps the same AA problem occurs(?)

Post a reply to this message

Attachments:
Download 'antialias_problem_with_bright_objects.png' (706 KB)

Preview of image 'antialias_problem_with_bright_objects.png'

BTW, sorry for the odd-looking PNG file; it's a gamma problem, probably due to
my old version of Photoshop. (The original image file shows up correctly on my
own computer, strangely.)

Here's a (hopefully) corrected JPEG version.

Post a reply to this message

Attachments:
Download 'antialias_problem_with_bright_objects.jpg' (359 KB)

Preview of image 'antialias_problem_with_bright_objects.jpg'

On 2021-02-11 3:12 PM (-4), Kenneth wrote:
> 
> To put it a simple way: When image pixels go over <1,1,1> in brightness
> (regardless of how), antialiasing starts to fail, both in the on-screen preview
> and in the saved image file. 
> 
> [snip]
> 
> In more detail: Since antialiasing involves shooting many rays into a scene per
> pixel (rather than just one ray), then averaging(?) them to get a smooth result,
> it seems that the color/lighting computations for that pixel should be clamped
> at a maximum of <1,1,1> *before* the averaging is done. I don't know the inner
> workings of the antialiasing mechanism, so this is just my guess. For example,
> when a white object's pixel brightness is created by, say, emission 10, it
> should be automatically reduced to <1,1,1> before the AA 'averaging' scheme
> kicks in-- since 'white is white', and a typical low-dynamic-range 24-bit image
> can only reproduce pure white as <1,1,1> anyway, not <10,10,10>.

This is exactly what versions 3.5 and earlier did, and when I compare it 
to the newer post-clipped anti-aliasing, certain effects, such as 
highlights with blurred reflection, look pretty limp.  There is a 
trade-off between good hyper-white effects and good anti-aliasing, and 
on balance, I'd have to say I prefer the latter.  It is easier to post 
process hyper-white effects than to boost an image whose contrasts have 
been compromised by averaging out its brightest elements after they've 
*already* been clipped.

I've attached examples of identical scenes rendered in 3.5 and 3.6.  The 
fact is, white is not just white.

Solving the post-clipping aliasing problem sounds like an ideal 
application of luminous bloom, which is being discussed in the "A Quiet 
Lane" thread.  GIMP and Photoshop also have post-processing options.

Sam Benge has created luminous bloom post-processors in POV-Ray SDL. 
This is the latest I have, though I do not know if he's done any further 
work.

   https://news.povray.org/4c2515e4%40news.povray.org

> There *is* a simplistic way of correcting this in pure radiosity scenes-- at
> least in certain circumstances-- by making two identical objects, one invisible
> with the high required emission value, and one that's visible but with an
> emission value of 1.0 (and a no_radiosity flag). But this scheme could get
> cumbersome.

It would also be problematic in reflections, as the object would appear 
too dark reflected in any object that reflects less than 100%.

Post a reply to this message

Attachments:
Download 'micronormal-v3.5-preclipped.png' (252 KB) Download 'micronormal-v3.6-postclipped.png' (254 KB)

Preview of image 'micronormal-v3.5-preclipped.png'

Preview of image 'micronormal-v3.6-postclipped.png'

> BTW, sorry for the odd-looking PNG file; it's a gamma problem, probably due to
> my old version of Photoshop. (The original image file shows up correctly on my
> own computer, strangely.)
> 
> Here's a (hopefully) corrected JPEG version.
> 

Do you mean that you set POV-Ray to save the image as a JPEG ? By 
default, it saves the images as PNG.

The PNG version look good here. (Mozilla Thunderbird) Maybe the 
application that you use to show the posted image don't handle PNG gamma 
chunk properly.

Post a reply to this message

On 2/11/21 2:12 PM, Kenneth wrote:
> I've been away from the newsgroups for awhile-- busy running lots of radiosity
> tests (and fixing computer problems). Along the way, I noticed something about
> the renders that has nothing to do with radiosity, but with antialiasing.
> 
...
> 

A little of what you are seeing I believe is related to the AA 
discussions in the threads (exploration you more or less got me into :-)).

http://news.povray.org/povray.general/thread/%3C5f9c4a2f%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5f9d5730%241%40news.povray.org%3E/


In other words, more flexible AA helps - a little.

---

To support the high dynamic range outputs not sure what can be done 
except some kind of post processing as Cousin Ricky suggested. At the 
time AA is done it knows about the color channel values and nothing 
more. With color values >>1 there simply is a massive difference between 
adjacent pixels. If you have say emission 10 even with some sort of 
bloom / blend, you'll need consume 10 or more pixels around the ultra 
bright regions to get into a range were you'd get AA on the '<=1.0' edge.

I had the thought this morning one way to post process using big jitter 
aa would be to output to hdr or exr, read the image back in dividing by 
the largest 'emission' value. Output, re-scale up the intensity, but 
clamping channels at 1.0 (or what ever). Probably would need to handle 
each color channel separately.

Attached is an image where in the top row you see the current output to 
png with clamping to 1.0 for the two right spheres at emission 5 and 9.9.

When I write to exr or hdr I was expecting linear encoded values, but 
this is not what I see...

To get what I wanted in the bottom row reading the exr/hdr images back 
into POV-Ray, instead of dividing by 9.9 as I believe is correct if 
everything linear, I had to divide by 174.125. A value which looks to 
have been gamma corrected.

Gimp agrees the written exr/hdr values have been gamma corrected. I've 
not looked into other exr/hdr dump value utilities

I believe exr and hdr input and output are supposed to be linear. Am I 
missing something? I don't have very much experience using exr, hdr. 
Except to use ones others have generated for environmental lighting and 
the read path seems OK.

I tried things like File_Gamma and gamma controls, but as the docs say 
these appeared to be ignored for exr/hdr files.

Bill P.

Aside: As a speed up for parametrics I'd played with writing the three 
x,y,z channels to image files. Using function based on those image files 
in scene instead, but the surfaces were very rough. I attributed it to 
not enough bit depth, but if the exr files were not linear, that could 
be why the method didn't work very well.

Post a reply to this message

Attachments:
Download 'hdr_exr_notlookinglinear.jpg' (57 KB)

Preview of image 'hdr_exr_notlookinglinear.jpg'

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> This is exactly what versions 3.5 and earlier did, and when I compare it
> to the newer post-clipped anti-aliasing, certain effects, such as
> highlights with blurred reflection, look pretty limp.  There is a
> trade-off between good hyper-white effects and good anti-aliasing, and
> on balance, I'd have to say I prefer the latter.  It is easier to post
> process hyper-white effects than to boost an image whose contrasts have
> been compromised by averaging out its brightest elements after they've
> *already* been clipped.
>

Thanks to you and William for the in-depth analysis. Looks like this subject is
an old one ;-) I'm still absorbing the details.

I guess I'm not yet fully understanding the visual flaws or contrast differences
produced by 'pre-clipping' extra-bright pixels vs. 'post-clipping.' From your
images, the differences seem to be very subtle(?)

I just downloaded sbenge's 'luminous bloom' post-processing tool (thanks for the
link) but haven't tried using it yet, or looking over the code. From his older
posted images, the bloom effect appears to affect the entire image, rather than
just the too-bright pixels. Maybe I'm mistaken? And does it work with a typical
pre-rendered low-dynamic-range image, or just with some kind of HDR-rendering
scheme? Sorry if these are naive questions; his older comments deal solely with
HDR, AFAIK. (I did a newsgroup search for 'luminous bloom', but could not find
much info regarding LDR renders.)

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:

> >
> > Here's a (hopefully) corrected JPEG version.
> >
>
> Do you mean that you set POV-Ray to save the image as a JPEG ? By
> default, it saves the images as PNG.
>

No, the 2nd image I uploaded (JPEG) was made by taking my original saved PNG
image (assembled in my old Photoshop v5), re-loading it into PS, and re-saving
it as JPEG. I trust PS to at least do *that* accurately ;-)  The original
POV-ray renders were PNG files.

[Btw, I use Windows 7, with a "system default sRGB" ICC color profile.]

> The PNG version look good here. (Mozilla Thunderbird) Maybe the
> application that you use to show the posted image don't handle PNG gamma
> chunk properly.

The basic problem is that my old Photoshop apparently saves PNG files with a
*very* wrong embedded gamma-- 4.4 (!) (I should have known better, and checked
my PNG image in Ive's IC/Lilysoft viewer app before uploading it; his is the
only app I have that shows the *true* embedded gamma of the image.) ALL of my
other viewer apps automatically correct(??) the gamma when presenting the
image-- which I truly don't understand. In older newsgroup posts, I've read
various comments that say something like, "A PNG image will appear correct in
any viewing app". So perhaps my nutty version of Photoshop embeds a gamma value
when it should not embed anything at all?

It is interesing that Thunderbird shows my uploaded PNG image as 'looking
correct', like my other apps do; whereas the newsgroup webpage I use shows the
bad (but *actually* correct) 4.4 embedded gamma. Apparently, the newsgroup page
is a more 'strict' interpreter of the actual image gamma-- like Ive's IC app.
But which situation is actually  correct, as to expected PNG-viewing behavior?
That has always been a mystery to me, even on my own computer. Are all of my
other apps wrong when they 'correct' for bad gamma? Or are they doing what they
are supposed to do?

Obviously, I need a better version of Photoshop. But it's such a workhorse app
for me that I don't want to change it (or to pay Adobe's monthly usage fees.) So
I *usually* stick to making JPEGs with it, not PNGs.

Post a reply to this message

Attachments:
Download 'gamma_problem_with_photoshop_5.jpg' (401 KB)

Preview of image 'gamma_problem_with_photoshop_5.jpg'

Op 13/02/2021 om 21:09 schreef Kenneth:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>>
>> This is exactly what versions 3.5 and earlier did, and when I compare it
>> to the newer post-clipped anti-aliasing, certain effects, such as
>> highlights with blurred reflection, look pretty limp.  There is a
>> trade-off between good hyper-white effects and good anti-aliasing, and
>> on balance, I'd have to say I prefer the latter.  It is easier to post
>> process hyper-white effects than to boost an image whose contrasts have
>> been compromised by averaging out its brightest elements after they've
>> *already* been clipped.
>>
> 
> Thanks to you and William for the in-depth analysis. Looks like this subject is
> an old one ;-) I'm still absorbing the details.
> 
> I guess I'm not yet fully understanding the visual flaws or contrast differences
> produced by 'pre-clipping' extra-bright pixels vs. 'post-clipping.' From your
> images, the differences seem to be very subtle(?)
> 
> I just downloaded sbenge's 'luminous bloom' post-processing tool (thanks for the
> link) but haven't tried using it yet, or looking over the code. From his older
> posted images, the bloom effect appears to affect the entire image, rather than
> just the too-bright pixels. Maybe I'm mistaken? And does it work with a typical
> pre-rendered low-dynamic-range image, or just with some kind of HDR-rendering
> scheme? Sorry if these are naive questions; his older comments deal solely with
> HDR, AFAIK. (I did a newsgroup search for 'luminous bloom', but could not find
> much info regarding LDR renders.)
> 

When I recently used Sam's Bloom (version 6 btw) I changed a couple of 
things:
- added: #version 3.8;
- changed the default to: #default{finish{emission 1}} (instead of 
#default{finish{ambient 1}}
- changed the image_pw to 1.0 (all images use gamma 1.0 now, not only 
HDR like in Sam's time)

This I used for the blooming A Quiet Lane scene; with some extra 
tweaking of course, but those are the fundamental changes.

-- 
Thomas

Post a reply to this message

On 2/13/21 6:39 AM, William F Pokorny wrote:
> On 2/11/21 2:12 PM, Kenneth wrote:
...
> 
> When I write to exr or hdr I was expecting linear encoded values, but 
> this is not what I see...
> 
> To get what I wanted in the bottom row reading the exr/hdr images back 
> into POV-Ray, instead of dividing by 9.9 as I believe is correct if 
> everything linear, I had to divide by 174.125. A value which looks to 
> have been gamma corrected.
> 
...
> 
> I believe exr and hdr input and output are supposed to be linear. 

Comments in the code say this is the intent. It is not what is happening 
on write...

> 
> I tried things like File_Gamma and gamma controls, but as the docs say 
> these appeared to be ignored for exr/hdr files.

I must have done something stupid previously while trying to gamma 
correct on the read of POV-Ray written hdr/exr image files.

After looking at some code, it was apparent the read functions allowed a 
gamma spec "to handle a non-compliant file."

Comments from the code:

// Radiance HDR files store linear color values by default, so never
// convert unless the user overrides (e.g. to handle a non-compliant
// file).

// OpenEXR files store linear color values by default, so never
// convert unless the user overrides (e.g. to handle a
// non-compliant file).

When I - again - tried reading exr files with a correcting gamma of 
0.454545, I could divide incoming values by the expect 9.9 max emission 
value and normalize to the 0-1 range as expected...

POV-Ray's written hdr and exr files are not linear.

Worse,and against my assumptions that hdr and exr were 32 bit float per 
channel formats; As implemented by POV-Ray they are only really useful 
for the representation of high dynamic range images.

The hdr format where it says 32 bit apparently means 32 bits combined 
RGBE (three R,G,B 8 bit channels and an 8 bit 'shared' exponent...) The 
exr format - which I have looked at less - as implemented, looks to be 
using half floats (16 bits less the exponent) per channel. Though 
openexr supports 32bit floats per channel.

All this means these two formats are more or less useless compared to 
other 16 bit per channel formats - IF aiming to maintain the greatest 
number of significant digits and not represent dynamic range.

As to why the write output is getting gamma corrected, it's not clear to 
me at the moment. The code more or less "reads" right, but when I add 
throws to the NeutralGammaCurve functions like Encode, Decode in 
colorspace.cpp,the render doesn't crash (doesn't reach those linear 
versions) as I believe it should.

This a v3.7, v3.8 issue. These formats were not in v3.6 or prior though 
IIRC they were in megapov (v3.6 based).

Bill P.

Post a reply to this message

> Alain Martel <kua### [at] videotronca> wrote:

>>>
>>> Here's a (hopefully) corrected JPEG version.
>>>
>>
>> Do you mean that you set POV-Ray to save the image as a JPEG ? By
>> default, it saves the images as PNG.
>>
> 
> No, the 2nd image I uploaded (JPEG) was made by taking my original saved PNG
> image (assembled in my old Photoshop v5), re-loading it into PS, and re-saving
> it as JPEG. I trust PS to at least do *that* accurately ;-)  The original
> POV-ray renders were PNG files.
> 
> [Btw, I use Windows 7, with a "system default sRGB" ICC color profile.]
> 
>> The PNG version look good here. (Mozilla Thunderbird) Maybe the
>> application that you use to show the posted image don't handle PNG gamma
>> chunk properly.
> 
> The basic problem is that my old Photoshop apparently saves PNG files with a
> *very* wrong embedded gamma-- 4.4 (!) (I should have known better, and checked
> my PNG image in Ive's IC/Lilysoft viewer app before uploading it; his is the
> only app I have that shows the *true* embedded gamma of the image.) ALL of my
> other viewer apps automatically correct(??) the gamma when presenting the
> image-- which I truly don't understand. In older newsgroup posts, I've read
> various comments that say something like, "A PNG image will appear correct in
> any viewing app". So perhaps my nutty version of Photoshop embeds a gamma value
> when it should not embed anything at all?
> 

OK then, my question is : Why did you post process your image in 
Photoshop ? You could have just posted the original, untouched, PNG.

Was it to resize it ? Then, for that task, Photoshop is gross overkill. 
If I want to do that, I'd use IrfanView. It's lightweight, free, can 
perform the combining of several images as you did and properly handle 
the PNG gamma.

Post a reply to this message