Edouard schrieb:

> And I'd like to say that any frustration that leaks through in my posts about
> gamma is in no way directed at you - you are in fact the person who is trying to
> fix the mess POV is in now, and for that I am genuinely grateful. Any
> frustration is my own issues about what a mess the entire computer industry has
> gotten itself into, and how near impossible it is to properly fix the situation
> without breaking most existing content (which in turn causes many users to want
> to stick to their existing broken content, as they neither understand, nor have
> the time to fix it themselves).

Let me assure you in turn that the opposition I exhibit in my postings 
is solely targeted at that frustration. Even while I'm arguing how 
POV-Ray is doing nothing wrong, I still take your postings as an 
incentive to ponder how POV-Ray can be made even better.


>>> I can see it's displayed correctly. That's great. But you've taken the decision
>>> that the file should be output with that display gamma baked in, and that's not
>>> something that's desirable under all circumstances (like, for example, any
>>> manipulation of the image afterwards).
>> No, this is absolutely the proper way to do it with PNG image files, as
>> per the PNG file specification.
> 
> I agree that you've implemented one possible implementation, in complete
> accordance with the PNG spec. I don't think that it is the only way to implement
> it however.

Just to get things straight, I'd like to point out that it was /not me/ 
who implemented the PNG output file gamma handling. As a matter of fact, 
absolutely /nothing/ regarding gamma you see in POV-Ray 3.4.0.beta.34 is 
my work. I will take neither blame nor praise for it. While I did some 
coding for input file gamma handling, those changes are still pending 
release.


>>>> Note that Photoshop lies to you about brightness (and so do your eyes).
>>>> Photoshop also uses physically wrong math when blurring images (at least
>>>> the old version I own does).
>>> No - Photoshop is doing a sensible thing, and that's to work in linear space
>>> (exactly the same way that POV does). Photoshop is a production tool, and having
>>> gamma applied half way through your workflow will just screw everything up.
>> No, that's exactly the problem: Photoshop is /not/ working in linear
>> space - it happens to work in /whatever/ space the image happens to be
>> encoded in.
> 
> No - Photoshop has the notion of a workspace profile - the profile that you are
> manipulating the image in. It can differ from the image's profile, and it can
> differ from the output profile. In a production workflow, you might not even
> know the final output profile, or there may be several (e.g. it needs to be
> displayed on a web page, put in a video to be broadcast, and printed in a
> magazine). That's the point of having colour profiles attached to your content.

Then it all boils down to you picking the right working profile, no? 
Photoshop should then get along with whatever the input file gamma or 
color profile may be - and in the absence of such a profile should 
assume something sane, like sRGB.

 From your griping I must conclude that this is not the case however, so 
Photoshop must be doing something wrong in that workflow.


>> As linear encoding gives a great deal of precision loss with
>> low-brightness values (at the benefit of some precision gain with
>> high-brightness values, where it's not really needed), thereby leading
>> to color banding in dark areas, linear encoding is /not/ suited for
>> 8-bit color depth images.
> 
> This is a separate argument that has unfortunately conflated with gamma
> correction. Yes, human perception of luminosity is non-linear, but don't mix
> that up with the gamma argument. There are separate ways of dealing with that
> issue

Actually, I'm beginning to prefer speaking of gamma /encoding/. 
Nowadays, the number of serious software still requiring /gamma 
pre-correction/ has drastically diminished.

As a matter of fact, when speaking of PNG files, as per specification 
we're talking about /gamma encoding/ anyway.


 > (and it's 2009 - a 16bit PNG file really isn't a big deal any more...)

There are still a lot of use cases where users will want 8-bit depth 
output, and for such cases gamma encoding is virtually a must. Which in 
turn mandates to default to gamma encoding for 16-bit PNG as well, to 
keep things consistent and the code simple.


>> Sure it is; however, color banding is a bad thing, and therefore 8-bit
>> linear encoded PNG is /not/ an option either.
> 
> Actually I almost always render to a Radience HDR file.

I've seen serious color banding there, too, by the way (I guess 
gradients from pure blue to pastel blue are particularly susceptible). 
While I was all the rage for HDR when I discovered MegaPOV, I now 
definitely prefer OpenEXR.

 > My opinion is that an
> 8bit image isn't suited for anything other than final display. All my workflow
> should be in HDR, or, as a last resort, 16bit. Otherwise most operations you
> perform on the image will lead to noticeable degradation, whether you have a
> linear or non-linear 8bit image.

If your workflow starts with HDR anyway, then why do you worry about 
PNG? :-P


> As a final output image, linear is fine, surprisingly enough. Photoshop, for
> example, will dither images when you apply a linear profile to an 8bit image -
> you can't tell the difference, as that leaves no visible banding when displayed.

As a side note, older versions of Photoshop, like 6.0 (and hobbyists may 
still have those in use to cut costs... at least I for one do) did /not/ 
support such fancy things as HDR or 16-bit PNG.


> What do we need for the ICC profile? Gamma - which we have. RGB values - which
> are implied in the code (otherwise things like dispersion wouldn't work).

Let's rephrase that: "(otherwise things like dispersion would give 
physically inaccurate results)" - which is exactly what they do.

There is presently /no/ piece of code in all of POV-Ray that is really 
color-space-aware.

 > And a
> whitepoint - which we don't explicitly have, but I think you've more or less
> decided that we are working in sRGB space, so that implies D65.

Though sRGB may likely become the default color space to interface to 
the outside world (and will for sure be the first to get some 
rudimentary support, by implementing its transfer function as an 
alternative to a power-law gamma curve), I'm pretty much sure that it 
will /not/ be the one to use internally. I don't think all parts of 
POV-Ray are ready to properly handle negative color values, so some 
wide-gamut color space should definitely be preferred.

If I'm asked, I'd personally prefer to use a spectral color model, using 
at least 4 (better yet 6) distinct bands. With intersection tests 
constituting the heaviest workload, and modern compilers and CPUs being 
good at vectorization optimization, I don't think it will impact 
performance too much.

> If we have those, then we have all we need for an ICC profile.

As you see, however, we don't have all of those yet. We're getting a 
well-defined gamma, and that's a start, but everything else is still 
wanting.

> Plus I'd love a future version of POV to support different profiles. People
> already use this when they write scenes with Jaime Vives Piqueres' LightSys
> macros. Imagine if the information about the colourspace and illuminant from
> those macros could simply be reflected into the output file.

Yes, that would be great. And once we do have proper color management, 
it shouldn't be much of a problem to do color space transformations. But 
alas! we're not there yet.

>> And don't complain about any color banding you may observe: You're
>> asking for it.
> 
> As I said above, I don't get any banding when I use a tool like Photoshop to
> apply a linear profile to an 8bit image.

But that again implies that the POV-Ray output you're working with /is/ 
using gamma encoding, doesn't it?

>> (BTW, to scale a gamma-encoded image without messing up the colors, I
>> can highly recommend IC. It does properly convert the image to linear
>> color space before resampling.)
> 
> If I assign a linear profile to the image, then every graphics program scales
> the image correctly. That really does seem like a better outcome to me...

You were reporting problems with that workflow though, didn't you?


Well, maybe I know too little of color profiles, and totally 
misunderstand the term "linear profile". Dunno.

Post a reply to this message