This is a very interesting article and in the discussion section for the
article I have already made extensive comments. But you raise some
interesting points.
I've looked through your comments there... very interesting. In
particular, I like the idea of using lprof directly for the RGB->XYZ
conversion... the scriptie didn't even run for me.
There is one vendor that is at least a little interested in this market
segment but they appear to have concerns that need to be resolved before any
progress will be made. The major issue is that the less expensive devices
that we are talking about are at least in part implemented in software. This
is significantly differnet from devices like the Spectrolino where everything
is implemented in the hardware. As a result the vendor(s) need to figure
out how to make that software (the drivers or interface library) available to
Linux/Unix/BSD users without exposing implementation details. This is not a
simple or inexpensive task and there are a lot of issues that they need to
deal with to make this possible. In the end I think this can be resolved but
the vendors are used to how things work for the Windows market place and are
having a very hard time understanding how to deal with the OSS world.
Yeah, it's a typical problem. I have yet to see a *good*
transition to OSS from any company/product like that. I'd hate to see it
go the nvidia binary-only route. That just leads to trouble.
I'm rather ignorant of what's in a colorimeter, but I'd imagine
it's not too horibly complicated. Certainly little to be proprietary....
just the sensor calibration is what's tricky. I'm assuming it's just
tri-color sensor that just has well-known spectral response curves?
Sure doesn't seem like it would be all that difficult to make one
of these little buggers go... IF you knew/trusted the numbers it gave
back.
You are correct about the devices supported by Argyll but I would have phrased
it is as "the devices are either old and difficult to obtain or relatively
expensive" since the Spectrolino is still in production but too expensive for
many users (over. $3000 list).
Ummm.. yeah.
The ability of current versions of LPROF to generate quality camera profiles
is the best it has ever been. But determining the accuracy of the camera
profiles generated by it or any other software is at best problematic. This
web page http://www.tkupfer.de/imaging/Scan_Profiling.html evaluates a number
of profilers including an older version of LPROF and packages from most of
the major vendors at the time of the evaluation. The reviewer profiled
scanners for the evaluation which is a simpler task than profiling a camera
as there are fewer variables. LPROF had by far the lowest delta E numbers of
any of the packages evaluated and current version of LPROF is better than the
version tested both with respect to delta E numbers and particularly the
smoothness of the CLUT curves.
I hadn't run into that page before. Impressive. The new spline
fit in lprof-dev certainly does a good job on my DSLR.
I think the question of how much impact ambient light has on the technique is
an open question. The author does not state what the ambient light
conditions were when capturing the IT8.7 image from the monitor. I believe
that this is a critical question and a huge variable that needs to be
controlled. There are also a number of other variables that are not
discussed in the article that need to be explored and controlled.
Most DSLR cameras have way more gamut than a typical CRT and likely more than
most if not all currently available display devices. So I don't think that
this is an issue with the technique. I also expect that as digital camera
technology advances that we will see improved gamut and dynamic range.
That's encouraging.
I don't think it is possible that this technique, or a variation of it, would
result in profiles that are as good as those generated using a high quality
measuring device. But I think that if everything were done in just the
right way it might be possible to get profiles that are significantly better
than those generated using LPROF "Rough Monitor profiler". In other words
it has the potential to be a good "poor mans" technique and it may be the
only option available until/unless one of the hardware vendors starts to
provide measurement hardware interface software that works on Linux/Unix/BSD
machines.
Hal
Agreed. That's what I was trying to say before... it can't be as
good as dedicated hardware. I'll bet that it'd be a lot better than just
getting it close with contrast/brightness/gamma adjustments though. If
that's the case, then one could do reasonable-quality, color-managed
workflow under linux by just buying an IT8.7 chart (assuming they already
had a camera with RAW). Just shoot the target to cal the camera, then cal
the monitor with the camera. Like you said, it's easier than doing the
camera because you don't have the variable of illumination color casts.
It's all transmitted from the CRT.
Just as an aside, I figured there was no inherent reason to limit
the target to just an IT8, so I tried to generate one with argyll's
targen and printtarg. Got a target and cal file, but coulnd't figure out
how to make the equivalent of an .ITX target that lprof liked. It's got
potential to make LOTS of color points for monitor calibration.
-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