[argyllcms] Re: "Washed" / low contrast colors on calibrated display
- From: "Frédéric Crozat" <fred@xxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 7 Jan 2008 11:53:46 +0100
On Jan 7, 2008 2:59 AM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
> Frédéric Crozat wrote:
> > After a lot of trials with dispcal, I'm getting my first results but
> > I'm not really happy with them : images seems to lack vivid colors,
> > everything look "washed" (sorry if I'm not using the right term).
>
> It's difficult to make these sorts of subjective assessments if
> you don't know what colorspace the images you are looking at
> are in. As soon as you change a display to be in a different
> colorspace, the images "look bad". This doesn't necessarily
> mean that display is set badly.
All images I'm testing right now are designed to be display in sRGB
colorspace. Which is why
I'm currently focusing on calibration result and not on profiling result (yet).
> > I'm having the same results with different monitors (all LCD, one
> > medium-level Sony and two entry-level Belinea) , so I'm wondering if
> > I'm doing everything correctly. I've shown this to our art designer at
> > Mandriva (since she knows how stuff is supposed to look) and she
> > agreed with me colors look as if they were supposed to be printed,
> > which is not the intent for our Mandriva display background (for
> > instance).
>
> Right, but how have these backgrounds been created ?
Illustrator (or Photoshop) but the target has always been sRGB. You
can check them at
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/mandriva-theme/current/SOURCES/mandriva-theme.tar?revision=91945
(careful, it is a 54MB archive, see the PWP backgrounds )
> For instance, if they've been created interactively on a monitor
> set to some other colorspace, they will of course look bad
> when displayed on a monitor set to a different colorspace.
I understand that but she has been designing backgrounds for more than
8 years and we know
we can't get exactly the same result on most monitors (since 99%
aren't calibrated and moreover we don't use the same OS for design and
display) but we are kind of used to this and for my test, the result
is really different.
> Brightness depends on what you are trying to do. If
> you are trying to do soft proofing for instance, you
> will have some brightness level in mind dictated by
> the hard proofing booth you are comparing to, or
> the ambient brightens level. For good color judgement
> and low fatigue it's desirable that the display brightness
> roughly match that of the ambient lighting.
So, my guess would be to use the ambiam light detector to check what
is the current value of ambiant light and
tune brightness accordingly.
BTW, I'm wondering if it wouldn't be better to tune backlight and not
brightness in that case ?
> If you have specific requirements (trying to do
> soft proofing) then you may want to target a specific
> white point and brightness, and be prepared to
> compromise other aspects of the display to achieve this.
> By all means use the controls to move the display
> in the direction you want to go, and then use
> the calibration curves to get there. If you
> are moving far from native (especially on an LCD)
> you may find the side effects unacceptable though.
As I wrote above, I'm mostly interested in getting correct sRGB output
(but I know I'll be much more careful when choosing my next LCD
monitor ;)
> > (9300K, 6500 and user defined (ie only Red and Blue offset). However,
> > when I check color temperature with dispcal -R, I get a white point at
> > 5875K (when 9300K is chosen on monitor), 5190K (when choosing 6500K).
> > So, I'm wondering what is the best setting to choose (and if I should
> > force a value using -t ) ?
>
> Hard to say why that is. Either the monitor is lying (possible
> with an LCD - it's hard to move the white point that much without
> loosing significant brightness or level resolution), or the
> instrument isn't measuring the spectral content of that display
> accurately.
Moreover, my monitor is kind of old (2002), so at that time, LCD for
"average" consumer weren't
that precise, I guess (and most consumers were not searching that information).
> > Also, the only way to change black point and white point is to change
> > the user defined "temperature", so I can't get a low dE for both black
> > point and white point. Which one should I try to get with the smallest
> > dE ?
>
> You do what you can, and you decide how far to "push" it. The
> white point is more important, but you usually can't do much
> with an LCD.
Ok, I guess I'll stop playing with trying to change whitepoint and use
one of those "predefined", even if their
value look crazy.
> > BTW, there is a slight error in dispcal usage (-h) : -q accepts u
> > (ultra high), but it is not printed in usage ouput.
>
> Sigh. Because people seem to often do silly things when they see
> "ultra high". They choose it first and then complain that
> "it's really slow" or something. It's there just for me to test
> things (to "bracket" the range of the usable settings).
In that case, you should drop it from dispcal manual too ;)
I also tried adding "-v" and I must confess I found the output
extremely interesting. I'm wondering if it wouldn't be better to push
the "iteration x on y in progress" and "patch x on y" in the default
message (when -v is not set), it would give some progress output to
user.
--
Frederic Crozat
Other related posts:
