[argyllcms] Re: CC Profiles In X Specification and dispwin
- From: "Frédéric Crozat" <fred@xxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sun, 13 Jan 2008 00:42:50 +0100
On Jan 13, 2008 12:14 AM, Leonard Evens <len@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, 2008-01-12 at 22:29 +0100, Frédéric Crozat wrote:
> > On Jan 12, 2008 9:50 PM, Leonard Evens <len@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > > I clearly still don't understand some things, so please be patient with
> > > me. Just what is the distinction between the calibration" and
> > > "profile". I looked at my profile with iccdump, and it contains a
> > > whole lot of information with the last three tags being rTRC, gTRC, and
> > > bTRC. I've been assuming these are loaded in the Xserver as look up
> > > tables. I even tried to decipher the code in xcalib and other programs,
> > > so I think I understand how it is done. Which part of the profile
> > > would be loaded with xicc?
> >
> > xTRC tags are part of the calibration "section" of the color profile.
> > They are loaded into X server using dispwin (or xcalib). And they can
> > be computed using dispcal.
> >
> > Those informations could be incorrectly reset by gnome-screensaver if
> > they were loaded after gnome-screensaver startup.
>
> My problems with the screensaver seem to have disappeared. There may
> have been some intervening gnome upgrade, but if so, it was not the
> gnome-screensaver. It is possible it was power savings that did it, and
> I just confused the two. But I'm not really concerned about that right
> now.
current version of gnome-screensaver has restoring calibration set at
gnome-screensaver daemon startup, so
it depends when you load the calibration data. But I think I also saw
some report about suspend not restoring LUT table (but it might driver
specific).
(as a note, I incorrectly wrote xTRC were calibration data, but they
are profiling data, as corrected by Gerhard).
> > The other part of a profile is characterization (or profiling). The
> > idea is that color requested (from a file, an application) might not
> > be displayable on a calibrated monitor. So, an color engine will try,
> > based on characterization data (obtained with dispread, for instance)
> > to translate colors requested to color displayable (I'm not sure I'm
> > very clear but I'm sure people will correct me).
>
> So this might concern gamut, rendering intent, whitepoint or blackpoint
> if I understand correctly. I am going to attach the output of iccdump
> for my profile---verbosity 2, and perhaps someone can tell me just which
> tags in my case would be used for that additional information and
> perhaps even how they would be used by the application.
Vgct part is calibration data. Everything else is characterization
data (except description, of course). (feel free to correct me if I
write something stupid, guys ;)
> > You can check
> > http://www.normankoren.com/color_management_2A.html#Monitor_viewing
> > for a quite verbose schematic (I recommend reading
> > http://www.normankoren.com/color_management.html for a introduction of
> > color management).
>
> I've studied Norman Koren's web page several times. I've also read Real
> World Color Management from cover to cover---at least I looked at every
> page---and I've reread relevant sections several times. My current
> problems don't seem to be that I haven't studied the subject. If
> anything I've studied it too much. Unfortunately, there is so much
> there that it is hard to pull out what is relevant for your particular
> situation. In my case, some of the nitty gritty about how things are
> coded might be helpful, provided it doesn't drown me in detail.
I know the feeling, I'm discovering color management for only some weeks now ;)
And I'm trying to not go too much deeper.
> > > I am also still very confused about how an application like eog or gimp
> > > 2.4 is supposed to make use of this information. For example, in the
> > > gimp preferences, I have several choices. I can specify a display
> > > profile, but I don't understand whether or not I should be using it if I
> > > use xcalib. Would the luts be used twice in that case? I've been
> > > trying to resolve these issues by experimentation, but that hasn't yet
> > > been very helpful since the changes with different arrangements are not
> > > very large.
> >
> > you must use xcalib (or dispwin) to "calibrate" your display. And
> > then, either specify manually the same color profile in gimp for the
> > characterization part or use xicc and gimp will use those data when
> > you choose "try to use system monitor profile".
>
> I think I understand that. From my somewhat rudimentary understanding
> of the code, the luts are loaded by standard functions in X11 VidMode
> extensions. There is a structure and the programs just copy the
> information into it and X then takes care of the rest. I presume under
> these circumstance that if you load one set of numbers and then with
> another application load some other set of numbers, the second loading
> just writes over what was there previously. So at least for the
> monitor, you don't have to worry about composing curves when you only
> want one to be operative. I hope that is correct.
Not entirely (or your explanation is incomplete).
LUT data is only loaded by dispwin (or xcalib) and is never modified
by applications (except gnome-screensaver ;).
Gimp (or other color managed applications) are modifying their own
rendering (ie the colors they request X server to render), based on
display characterization data, in order to get expected colors (as
measured by colorimeter). This color management is not done by X
server but by applications, most of them using littleCMS library to
take care of it. This is why if you get a different rendering if you
disable color management in GIMP (or if you use a non color managed
application, such as gthumb or firefox 2), even if the display is
correctly calibrated, thanks to LUTs.
--
Frederic Crozat
Other related posts:
