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

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

> >
> > The basic problem is that my old Photoshop apparently saves PNG files with a
> > *very* wrong embedded gamma-- 4.4 (!) ...
>
> OK then, my question is : Why did you post process your image in
> Photoshop ? You could have just posted the original, untouched, PNG.

I used PS (my 'favorite' but flawed image-editing app) only because I needed to
combine my 6 original PNG POV-ray renders into a single presentation-- along
with text notes-- for posting here. Then I saved it as PNG-- a mistake.
*Usually*, I save the resulting single image as a JPEG, but I forgot that my
older PS has a gamma problem when saving a PNG file (even though the combined
image 'looks' correct in PS and most of my other apps.)
>
> 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.

As strange as it seems, I've never used Irfanview for such tasks(!) I only use
it as an image viewer, and not very often; Photoshop is just more familiar to
me.

Obviously, I need to investigate what Irfanview can do. Thanks for the 'nudge'
;-)

Post a reply to this message

On 2/14/21 9:48 AM, William F Pokorny wrote:
> 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...
>>
..
>>
>> 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...
> 

Got back to looking at this - and I got EXACTLY what I asked for in my 
coding in the scene file! All is good with POV-Ray.

I thought I was using linear encoding for the emission colors, but I was 
actually using srgb... (a)

My personal discoveries related to the exr(as used) and hdr formats not 
being useful for other than expressing dynamic range, stand. In other 
words, don't use these two formats for height fields and such.

Bill P.

(a) Growing up my family owned a small, single crew, tree service and 
one of my brothers has a small tree service of his own. A decade or more 
ago he suggested I read the book, "The Wild Trees." In it there's a 
story about an experienced climber taking a fall - while still thinking 
to yell "headache!" to those on the ground. His reason for falling came 
to being in that place where you trust your own skill too much. Twice in 
the last month that's been me with simple, quick scene files. My 
apologies for the false alarms. Please imagine, "HEADACHE!!!" in the 
subject line for my next post (or two) about there being a problem with 
POV-Ray. :-)

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/11/21 2:12 PM, Kenneth wrote:

> > I don't think the failed AA is simply the result of a difference
> > in contrast/brightness with surrounding darker pixels.

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

Yes, I understand that now; and I was wrong to say that the surrounding darker
pixels have no effect on the 'lack of AA' of super-bright ones. They obviously
do, from visual tests. Making the surrounding pixels brighter helps to improve
the failed AA.

And the idea of simply 'clamping' very-bright pixels to <1,1,1> is rather naive,
I admit. There are probably many lighting/color situations where only one of the
color-vector values ends up >> 1.0-- in which case, simply clamping the highest
vector value to 1.0 may shift the intended (expected?) color, unless some other
'equalizing' scheme is brought into play to shift the other two values in a
subtle way. [This is just my 'thought experiment', based on nothing but
intuition ;-) ]

Post a reply to this message

Op 17/02/2021 om 17:04 schreef William F Pokorny:
> On 2/14/21 9:48 AM, William F Pokorny wrote:
>> 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...
>>>
> ..
>>>
>>> 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...
>>
> 
> Got back to looking at this - and I got EXACTLY what I asked for in my 
> coding in the scene file! All is good with POV-Ray.
> 
> I thought I was using linear encoding for the emission colors, but I was 
> actually using srgb... (a)
> 
> My personal discoveries related to the exr(as used) and hdr formats not 
> being useful for other than expressing dynamic range, stand. In other 
> words, don't use these two formats for height fields and such.
> 

Yes, that is what I had always thought indeed.

> 
> (a) Growing up my family owned a small, single crew, tree service and 
> one of my brothers has a small tree service of his own. A decade or more 
> ago he suggested I read the book, "The Wild Trees." In it there's a 
> story about an experienced climber taking a fall - while still thinking 
> to yell "headache!" to those on the ground. His reason for falling came 
> to being in that place where you trust your own skill too much. Twice in 
> the last month that's been me with simple, quick scene files. My 
> apologies for the false alarms. Please imagine, "HEADACHE!!!" in the 
> subject line for my next post (or two) about there being a problem with 
> POV-Ray. :-)
> 

Noted.



-- 
Thomas

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> ...My apologies for the false alarms. Please imagine, "HEADACHE!!!" in the
> subject line for my next post (or two) about there being a problem with
> POV-Ray. :-)


Your ideas and detailed code-analysis presentations are *always* of interest, so
don't hesitate to speak up and bring them to our attention. Keep up the good
work with povr!

Post a reply to this message