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