 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/4/2009 11:58 PM, clipka wrote:
> If you're referring to setting up POV-Ray, then yes: The POV-Ray 3.6
> instructions how to identify the proper Display_Gamma setting for your
> system are still valid for 3.7.
The docs say, "Now, lower the contrast until the alternating white and
black bars on the left edge of each column are equal in width." What do
they mean?? Which width am I measuring?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SharkD schrieb:
> On 11/4/2009 11:58 PM, clipka wrote:
>> If you're referring to setting up POV-Ray, then yes: The POV-Ray 3.6
>> instructions how to identify the proper Display_Gamma setting for your
>> system are still valid for 3.7.
>
> The docs say, "Now, lower the contrast until the alternating white and
> black bars on the left edge of each column are equal in width." What do
> they mean?? Which width am I measuring?
Um... I must confess that it's been a while since I last read that
section of the docs.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
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 ;)
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
