[argyllcms] Re: Explain what happened

  • From: Leonard Evens <len@xxxxxxxxxxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Tue, 02 Dec 2008 22:02:02 -0600

On Wed, 2008-12-03 at 12:52 +1100, Graeme Gill wrote:
> Leonard Evens wrote:
> > I used
> > dispcal -v -yl -0 TargetA
> > with an Eye-One LT
> > I ignored the first set of numbered instructions because there are no
> > controls that I can adjust---which may have been a mistake---, and I
> > went directly to the last two steps: the check of ambient light and
> > making the profile.  It did produce a profile TargetA.icc.
> 
> I'm not sure why that happened. It shouldn't have produced a profile,
> since you didn't give it a -o parameter. (-O sets a profile description).
> Are you sure that your command line above is accurate, and that
> it wasn't in fact:

Thanks for your explanation explanation.  I will have to study your
response in detail, but, going through it quickly, I think it will go
quite far in answering my questions.
> 
>    dispcal -v -yl -o TargetA

That is in fact what I used.  the -0 above was a typo.

> 
> ???
> 
> Note that using dispcal -o, the monitor is both calibrated
> and then the calibrated monitor is profiled (ie. characterized).
> Naturally, the profile is only valid for the monitor in its
> calibrated state, that's why the calibration curves are (by
> convention) stored in the profile, so that the monitor
> can be set to the calibrated state whenever the profile
> is to be used.
> 
> > I assumed on the basis of what I thought I  understood that the
> > calibration part, i.e., loading the video LUT was irrelevant and that
> > the profile would be made under the assumption that it would do all the
> > work.   
> 
> I'm not sure why you thought that. The whole point of device characterization
> (profiling) is to record and model the color behaviour of the device.
> This means creating a equivalence between device color values and
> device independent (CIE - ie. human perception) color values. That mapping is
> then represented by an ICC profile model. Calibration changes the behaviour of
> a device by altering the way that device color values are
> converted to/from actual (human perception) color. So obviously a calibration
> state affects the profile. For a profile to be valid, it must
> be in the same calibration state it was when it was characterized.
> 
> You used dispcal to both calibrate and profile, so the profile
> is only valid if the monitor is put in its calibrated state.
> 
> > I then told gimp that TargetA.icc was the monitor profile.  But
> > that had no effect whatsoever on the colors that gimp put on the screen
> > in an image window. 
> 
> Sorry, I don't know how the Gimp handles (or doesn't handle) color profiles.
> If nothing changed, then either the profile was the same as the one
> the Gimp was already using, or there is no color space definition (profile)
> set for the image being displayed, or the Gimp isn't working the way one would
> expect when informing it of the monitor profile.
> [One wouldn't normally expect an application to set the monitor
>   to its calibrated state - this is more of an overall system
>   concern, not something an application that uses profiles should do,
>   hence the use of calibration loaders such as dispwin or xcalib
>   on operating systems that don't have this built in.]
> 
> > So I tried
> > xcalib TargetA.icc
> > and that immediately turned the background (which I had previously set
> > to R 128, G 128, B 128) to neutral gray.  (Before it has been the bluish
> > gray you sometimes get on un calibrated laptops.)  In other words a LUT
> > was in fact loaded in the video card.
> 
> Yes, xcalib loaded the calibration curves stored in the ICC profile
> onto the monitor, (hopefully) putting it in the calibrated state
> that dispcal created and then used for characterization.
> 
> It doesn't explain why the Gimp didn't change its display
> when you informed it of the monitor profile though. If the
> Gimp is actually doing color management, then it will have a
> definition of the color space of the pixels to be displayed,
> and will use that together with the monitor profile to transform
> the pixel values for display (ie., by linking the two profile
> together and transforming from the image color space to the
> calibrated monitor space).
> 
> > So I clearly don't really understand the distinction between calibrating
> > and profiling.  
> 
> Hopefully the above discussion helps.
> 
> > And I don't really understand what gimp color
> > management is doing.  
> 
> I'm not sure I can help you with that. Perhaps the Gimp
> mailing list might be a better forum ?
> 
> Graeme Gill.


Other related posts: