clipka <ano### [at] anonymousorg> wrote:
> Edouard schrieb:

(Deep breath)

OK. Let me start this again...

Let me, in fact, start by saying that you have done a truly outstanding job with
POV 3.7, and I (and I'm certain, many others) are hugely grateful for all the
hard work you've done - both in the fun parts (like SSLT) and the, I imagine,
tedious and/or frustrating parts like fixing radiosity, and, of course, trying
to fix the gamma issues. Without your work I'd still be using Megapov, and
wouldn't have even been able to write the DF3 proximity macros (as a good
example; they rely on your binary writing patch for 3.7).

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

Anyway:

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

Baking the gamma in, and using only the gAMA chunk is certainly valid, but there
are other ways that are more advanced, and allow users, programs and OSs to make
better choices and use of the image data.

But, as I've said, baking in the gamma is a good solution for users who want to
render an image, and then do nothing else but look at the results. So what
you've done is good.

Or, in my opinion, good for that scenario. There are other scenarios (or
use-cases) for which that isn't such a good option. So I'm not saying that your
implementation choice is wrong, just that it isn't suited for all use-cases.

There's another entire set of use-cases where it is desirable for the output
file to have linear response. And luckily PNG (and other formats) can quite
easily support this too. Unfortunately the gAMA chunk by itself isn't a good way
to implement this for PNG. ICC profiles are the best route to making this work
across the widest range of platforms and applications.

There are still other scenarios where a full ICC profile would be best, even
when not using linear gamma. Any content that is going into a professional
production environment more or less must use the facilities of a full colour
management system, and ICC profiles are the way to go.

To recap - there is no right way or wrong way, but there are a number use-cases,
and (unfortunately) they require different types of PNG file. Many of the
use-cases collapse down to 2 or 3 different PNG files, so it's actually not that
bad.

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

When I load a PNG file with a linear gamma ICC profile, Photoshop asks me
whether I want to work in the documents colourspace, or convert the image to my
working colourspace. This is a good thing, as the answer depends on what I'm
actually doing with the image. I can also change my working colourspace to any
profile including linear gamma. Also, good.

> 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 (and it's 2009 - a 16bit PNG file really isn't a big deal any more...)

> >> The /physical/ blurring by squinting your eyes, however, does indeed
> >> comprise a physically correct "computation" of (black+white)/2 (taking a
> >> few steps back may do the same job, and some people may just need to
> >> take off their glasses), which obviously gives you a grey of /truly/
> >> half the white value (*), which you can then visually compare to the
> >> grey of /allegedly/ half the white value.
> >
> > I'm arguing that for a digital artist who is using POV as part of their
> > workflow, having tools like Photoshop's blur give identical "output" to what you
> > see when you do the "squint" method, is a good thing.
>
> 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. 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.

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.

> > I'm sure lots of people will be happy to bake the gamma into their file if they
> > are producing "final" images with POV, and not intending to post-process them in
> > any way (as long as they know scaling the image is then a no-no). But there are
> > plenty of others who use POV in a workflow that includes scaling and other post
> > processing, and we would be better suited with having linear ICC profiles
> > attached to the images. There is no "right" way, it all depends on how the user
> > is intending to use the image.
>
> Feel free to use "File_Gamma=1.0" on the output file, which does exactly
> what you demand - except that it doesn't attach an ICC profile, but
> "only" a gAMA chunk, because an ICC profile would inevitably have to be
> a lie (POV-Ray is presently gamma- but not color space-aware). It's a
> shame that Photoshop 6.0 fails to support the gAMA chunk, but that's not
> POV-Ray's fault. And you can actually work around the problem by
> manually assigning your favorite linear ICC profile to the image /after/
> you have loaded it into Photoshop.

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

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

And once you have ICC profiles, then it becomes trivial to encode the file in
sRGB gamma, linear gamma, or even some custom gamma.

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.

> 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. Perhaps there are other tools out there
that don't do as good a job. It's a bit like non-dithered GIF images - they
looked highly posterised. The solution - no-one used a tool that could only
produce posterised images like that.

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

Cheers,
Edouard.

Post a reply to this message