[argyllcms] Re: Displaying sRGB graphics on wide gamut monitors - gamma problem?
- From: Anders Torger <torger@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 27 Oct 2010 14:05:32 +0200
I'm just starting to probe the rendering intents of different
applications.
I use Bibble5 which is hard-coded to perceptual. I use firefox for
viewing galleries on the web, and I have configured to render sRGB for
all untagged graphics (it will color manage ICC profile 2 with standard
setting). Firefox is also hard-coded to perceptual as far as I know.
As far as I understand - apart from black point compensation, perceptual
intent should be the same as relative intent for sRGB on a wide gamut
screen, and since I have calibrated to D65 it should be same as absolute
too, since there's a match of white point and sRGB fits within the
gamut. However, concerning gamma there might be differences... I could
imagine that perceptual intent is looser on gamma correction than
relative or absolute, if there is a standard for it.
However, as I understand it how rendering intents is actually rendered
by applications is not strictly standardized. For example if make a
perceptual renderer and shall show an sRGB image on a 2.4 gamma screen,
you may choose to not correcting for that. I'm not yet sure how this is
done, however my guess is that most perceptual renderers don't correct
gamma, but perhaps that's wrong? Is rendering intents strongly
standardized so one can be sure that all applications renders the same
way? Apart from gamma, it seems like black point compensation can be
made in several different ways and there's no standard for that either?
If the renderer would correct for the monitors gamma, I still have a
problem. I don't actually want 1.0 viewing gamma, since my ambient
lighting is low. So somehow the renderer would need to know how to
correct for that... but perhaps I can encode my viewing conditions in
the monitor's ICC-profile, and then good perceptual renderers will
adapt?
So far my assumption is that applications cannot really be trusted on
what they do, so it is best to do most calibration in dispcal (where you
actually can see what is done) and not leave so much need for correction
in the applications.
The experiment of not calibrating at all, just doing characterization
and let applications do all correction and compare that with calibration
was an eye-opener to me. As a layman one would think that there would be
no difference, but there really is a huge difference in how things look.
I currently would guess that there may be huge differences in how gamma
is handled and how black point (and white point) compensation is made.
But I seem to have lot to learn yet. Knowing what one *actually* sees
surely does not seem to be an easy thing...
/Anders
On Wednesday 27 October 2010, János, Tóth F. wrote:
> I think that the color management engine will take care about the
> gamma, gamut and WP together (if it's a proper one ; but the WP
> correction also depends on the used rendering intent mode, like
> Relative or Absolute colorimetric ; and you may have options to
> manually set other things...). The colors will be re-mixed to
> achieve the closest possible state.
>
> The problem can be the definition of the target values. Your
> calibration target doesn't really matter when you characterize your
> calibrated display and the software do the corrections (and you need
> software corrections for the gamut emulation).
> An example:
> You have a display with gamma 1.7
> You calibrate it to gamma 2.4 (imagine a 10+ bit display with
> accessible hardware LUTs...)
> You profile this calibrated display, so the software will know that
> you have a display with gamma 2.4
> The embedded profile in the sources (or the software's assumptions
> about these values for untagged sources - like sRGB for web
> contents, Rec709 for HD videos, etc.) is (for example) gamma 2.2
> Now, the software will do a correction to show you an image with
> gamma 2.2 gradiation (imagine that you use true 30 bit display mode
> ; or you can see some glitches as well, but it doesn't really matter
> here).
>
> This is one of the reasons why I played with the idea to skip the
> calibration and do a high quality profiling only.
> My softwares didn't worked well but may be you should give it a try.
>
> But this won't solve your problems with the target setup. (May be you
> have some manual controls for the CMS modul, and you can set some
> offsets. For example, a multiplier for the gamma, you would apply
> 2.4/2.2, but it depends on the software controls.)
>
> Or you can change your view conditions or others may have better
> ideas. :)
Other related posts:
