Marti, I have read the HP paper and it is very interesting. Under the right conditions the technique/algorithm they developed would allow for the accurate (+- 50K) characterization of the monitor whitepoint without a measurement instrument. But those conditions would be very difficult to reproduce in the real world.
It required that the room and all furnishings in the room be a dark neutral gray and that the person sitting at the computer be wearing black clothing and that there is no other light in the room other than that produced by the monitor. Not something a typical user can do. Note that these conditions result in the monitor whitepoint becoming the adapted whitepoint of the viewer because it is the only light source and the images displayed on the monitor are all neutral. The technique/algorithm is apparently very good at finding the adapted white point of the viewer and can do so under almost any lighting conditions but the best results were under the above viewing conditions or (close second) sRGB viewing conditions. Your typical "which gray patch is more neutral" way of finding the whitepoint, like that used by AdobeGamma, gives results for the adapted whitepoint that are typically off by as much as +- 1000K. So these may in fact be worse than making an educated guess. One of the more promising aspects of the Scibus Wiki article is that it appears to me that the technique for finding and setting the monitor whitepoint might actually be something that would work if it was done with enough care. The only way to confirm this would be to test this technique and variations against results from a known good measurement device. Something that I do not have the equipment to do. If this did in fact give reasonably close results then this would solve the whitepoint part of the rough monitor profiling problem which only leaves the transfer function problem to be solved. Current LPROF releases now use the Norman Koren gamma charts which do give much better and more consistent results than the old gamma charts. Again these charts need to be "calibrated" against a known measurement device. This has not been done and the current results, although very consistent and repeatable, may not be accurate in absolute terms. But the code does have a place were it can be tuned in order to correctly calibrate it. If anyone has the ability to compare the results from these charts against a measurement device this would be very helpful. Once the algorithm is correctly "calibrated" the mid point gamma would be very close to the actual transfer function. But the dark and light regions might still be off by a significant amount. Norman Koren also has dark and light versions of these same charts and it might be possible to have the user run through the dark, mid and bright gamma charts for each color channel and then integrate these into a single transfer function curve for each color channel to achieve a better transfer function than just using the mid point gamma. Hal On Saturday 04 March 2006 10:39 am, Marti wrote: > Hi, > > > Basically, it assumes that one can generate an accurate color profile > > for a digital camera, and then turn around and use it as a colorimeter to > > profile your monitor. > > I tried something similar long time ago, but didn't work at all. > The reasons were several, but mostly the error you get by using > a camera is too big to get suitable profiles. > > My work was largely based on CRT, and may not be valid for TFT > since thet are basically differnt beasts, but here are some ideas: > > - An ICC profile for CRT monitor can be built using just > matrix-shaper. > - Average error of matrix-shaper can be really low, sometimes > under < 1dE. Again, that's for CRT only > - Gamma-gain-offset model works great if you can add an offset to > refresent black point. > - Primaries mismatch is not so important, what makes a difference > (to the eye) is white point and transfer curves. > > Putting all together, you can do a reasonable ICC profile for a CRT > monitor by knowing white point, primary chromaticities and transfer > curves. Primaries are on most CRT very close to Rec709 (sRGB) > so you have to know transfer function (aka gamma) and white point. > > The missing part is how to characterize white point and transfer > curves without expensive hardware. I don't know either :-) > There has been some work on that. See for example HP's MIND > http://www.hpl.hp.com/techreports/1999/HPL-1999-158.pdf > But AFAIK there is still no clean solution. > > Regards > Marti Maria > The littleCMS project > http://www.littlecms.com > > > > ----- Original Message ----- > From: "Cory Papenfuss" <[EMAIL PROTECTED]> > To: <lcms-user@lists.sourceforge.net> > Sent: Saturday, March 04, 2006 3:48 PM > Subject: [Lcms-user] How feasible is this procedure? > > > I got off on the monitor profiling tangent a bit this morning, and as far > > as I can tell, nobody gives a crap about linux-land monitor colorimetry. > > Argyll allegedly supports two devices, but they're both old and > > expensive. Ran across this idea: > > > > http://wiki.scribus.net/index.php/Proposal_for_Monitor_Profiling > > > > Basically, it assumes that one can generate an accurate color profile > > for a digital camera, and then turn around and use it as a colorimeter to > > profile your monitor. > > > > Does this seem like a reasonable thing to do? I'm sure it's not as > > accurate as a puck-like object stuck directly on the screen, but with > > minimal ambient light it may be reasonable. The gamut of DSLRs in > > particular is comparable to CRT's, no? > > > > Intriguing... > > > > -Cory > > > > -- > > > > ************************************************************************* > > * Cory Papenfuss * > > * Electrical Engineering candidate Ph.D. graduate student * > > * Virginia Polytechnic Institute and State University * > > ************************************************************************* > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > language > > that extends applications into web and mobile media. Attend the live > > webcast > > and join the prime developer group breaking into this new coding > > territory! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > > _______________________________________________ > > Lcms-user mailing list > > Lcms-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/lcms-user > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Lcms-user mailing list > Lcms-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lcms-user ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
