POV-Ray : Newsgroups : povray.binaries.tutorials : Check(er) Your Gamma Server Time
31 Oct 2024 19:26:17 EDT (-0400)
  Check(er) Your Gamma (Message 15 to 24 of 24)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Ive
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 03:45:20
Message: <4af3e220$1@news.povray.org>
SharkD wrote:
> On 11/5/2009 6:43 PM, clipka wrote:
>> 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.
> 
> I thought that Photoshop always worked in LAB space?
> 
> Mike

Not *always*, e.g. for all kind of affine projections (this includes 
simple resizing) it does not.

-Ive


Post a reply to this message

From: Edouard
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 04:20:00
Message: <web.4af3e9732d58a2835b81d0ec0@news.povray.org>
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

From: Edouard
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 04:25:01
Message: <web.4af3eaec2d58a2835b81d0ec0@news.povray.org>
Ive <"ive### [at] lilysoftorg"> wrote:
> A quick note about Photoshop and it's PNG support:
>
> I'm using Photoshop since version 4.0 and currently CS3 (still not sure
> about updating to CS4) and every version had broken PNG support in one
> way or another. Usually the gamma and sRGB chunk was ignored, some
> version did completely mess up 16 bps images and CS3 writes colorimetric
> chunks (color primaries and whitepoint) but 'forgets' to add the gamma
> chunk (and it claims when saving to PNG that this file format does not
> support any metadata - a plain lie because PNG even supports XMP, the
> way that is favored by Adobe itself for storing metadata).
> Given the long time and that PNG is a quite simple format it seems not
> that far fetched that PNG support is broken deliberately - as some
> people claim - but I fail to see the reason behind it.

Yes - it should write the gamma chunk when adding  profile. It says so in the
spec.

I think PNG has never been a "pro" format in terms of their production
customers, so Adobe hasn't given it the love. I don't think it's anything more
sinister than that.

Photoshop 4? Pah - luxury! I started using version 2.0 - it didn't even have
layers!

> clipka wrote:
> |...]
> > (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.)
>
> Thanks for the advertising ;)

When's the Mac version coming out? :-)

> -Ive

Cheers,
Edouard.


Post a reply to this message

From: Ive
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 05:15:08
Message: <4af3f72c$1@news.povray.org>
Edouard wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> A quick note about Photoshop and it's PNG support:
>>
>> I'm using Photoshop since version 4.0 and currently CS3 (still not sure
>> about updating to CS4) and every version had broken PNG support in one
>> way or another. Usually the gamma and sRGB chunk was ignored, some
>> version did completely mess up 16 bps images and CS3 writes colorimetric
>> chunks (color primaries and whitepoint) but 'forgets' to add the gamma
>> chunk (and it claims when saving to PNG that this file format does not
>> support any metadata - a plain lie because PNG even supports XMP, the
>> way that is favored by Adobe itself for storing metadata).
>> Given the long time and that PNG is a quite simple format it seems not
>> that far fetched that PNG support is broken deliberately - as some
>> people claim - but I fail to see the reason behind it.
> 
> Yes - it should write the gamma chunk when adding  profile. It says so in the
> spec.
> 
> I think PNG has never been a "pro" format in terms of their production
> customers, so Adobe hasn't given it the love. I don't think it's anything more
> sinister than that.
> 
> Photoshop 4? Pah - luxury! I started using version 2.0 - it didn't even have
> layers!


Photoshop 2.0? Pah, in fact I started with Aldus Photo-Styler. Aldus was 
later 'consumed' by Adobe (a company that had nothing to do with image 
processing at this time) and Photoshop 1.0 was nothing but the Aldus 
Photo-Styler with a new name. I had some break in my life back then and 
did start to make a living as musician but returned to IT business when 
Photoshop 4.0 was out.
And BTW Aldus did also maintain the TIFF specification and so it 
happened that the TIFF specs are now 'owned' by Adobe and the latest 
revision 6.0 is from 1992 (!!!) even if Adobe has greatly extended the 
format simply by adding lots of new features regarding TIFF into 
Photoshop...

-Ive


Post a reply to this message

From: clipka
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 07:48:23
Message: <4af41b17$1@news.povray.org>
Ive schrieb:

> Thanks for the advertising ;)

To counterbalance it a bit: It does have flaws :-P What bothers me most 
is that whenever I re-render any image file in whatever directory IC is 
presently in, any subsequent attempt to skip to the next or previous 
image - or even just choose "reopen image" - makes it jump to the first 
image in the directory instead, which I think makes that "reopen image" 
business pretty much pointless... (using version 1.0.10 here)

Still, it has definitely become my favorite tool for "low-level" 
post-processing, such as resizing, color correcting, and conveting 
between image file formats. And to get rid of color banding in some 
exceptionally problematic scenes: Rendering to OpenEXR and then 
converting in IC to whatever file format I really want /always/ does the 
job.

(I wonder why nobody ever bothered to add a "dither" switch to 
POV-Ray... or did I miss something?)


Post a reply to this message

From: clipka
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 09:04:54
Message: <4af42d06$1@news.povray.org>
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

From: SharkD
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 09:48:05
Message: <4af43725$1@news.povray.org>
On 11/6/2009 12:49 AM, clipka wrote:
> I'd recommend to just skip the brightness and contrast stuff (you should
> have done that already when calibrating the display), and just do the
> eyes-squinting part and following.

Except that now I'm confused and can't remember *which* eye-squinting 
instructions I'm supposed to follow...

Is there no tool where I can just click a button and say, "Fix my gamma!"?

Mike


Post a reply to this message

From: Ive
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 09:54:46
Message: <4af438b6@news.povray.org>
clipka wrote:
> To counterbalance it a bit: It does have flaws :-P What bothers me most 
> is that whenever I re-render any image file in whatever directory IC is 
> presently in, any subsequent attempt to skip to the next or previous 
> image - or even just choose "reopen image" - makes it jump to the first 
> image in the directory instead, which I think makes that "reopen image" 
> business pretty much pointless... (using version 1.0.10 here)
> 

Good to know, guess I messed things up when wrapping OS specific 
functionality (like directory monitoring) to prepare for a future 
cross-platform GUI. IC is in fact just the graphical front-end for a 
professional image processing library and as such basically just a hobby 
of mine and I have quite limited time for testing it. So I'm quite 
thankful for all feedback from users, especially about things that do 
not work as expected.

> 
> (I wonder why nobody ever bothered to add a "dither" switch to 
> POV-Ray... or did I miss something?)

I *think* there was once a dither option for color palette based image 
file formats like GIF ;)

-Ive


Post a reply to this message

From: clipka
Subject: Re: Check(er) Your Gamma
Date: 6 Nov 2009 17:55:31
Message: <4af4a963$1@news.povray.org>
SharkD schrieb:
> On 11/6/2009 12:49 AM, clipka wrote:
>> I'd recommend to just skip the brightness and contrast stuff (you should
>> have done that already when calibrating the display), and just do the
>> eyes-squinting part and following.
> 
> Except that now I'm confused and can't remember *which* eye-squinting 
> instructions I'm supposed to follow...
> 
> Is there no tool where I can just click a button and say, "Fix my gamma!"?

I wish there was. However, as far as POV-Ray is concerned, the next beta 
should provide proper gamma handling almost "out of the box".


Post a reply to this message

From: Thomas de Groot
Subject: Re: Check(er) Your Gamma
Date: 11 Jan 2010 10:57:46
Message: <4b4b4a7a@news.povray.org>
Following this test, to all who find my images washed out, I am glad to say 
that my hardware and software are properly calibrated  :-)

Thanks Cristoph.

Thomas


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.