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" <papenfuss juneau.me.vt.edu>
> To: <lcms-userlists.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_M
onitor_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-userlists.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-userlists.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-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
|