[argyllcms] Re: 1st post
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 08 Dec 2010 23:01:52 +1100
Knut Inge wrote:
combining the response into something similar. After som googling, I have
the impression that the Spyder 3 line share the same basic sensor and that
it does fairly well for wide-gamut displays?
There seem to be a variety of reports, some good, some not so good.
How much of this is software? I.e., if I had access to 3 or 4 different
calibration softwares, using my Spyder 3 express, would they give very
different results? I assume that any application with correction matrixes
for my sensor (possibly in combination with WGC displays, or even my model
display) will have an upper hand, but other than that, the profiling is more
mathematics and sensible regularization than magic?
I don't have much experience with display calibration software other than
my own, so it's hard to say. A general rule though is that you trade
off speed against accuracy and robustness. If you make
assumptions about how a display behaves, you can get away with far
fewer measurements. This worked rather well for CRT displays, because
the basic physics was pretty constant. I'm not sure if it works so
reliably for LCD's, where you don't get to see the underlying LCD behaviour,
because it's modified quite extensively by the electronics in an attempt
to make it emulate CRT behaviour.
My display came with a color calibration factory report, stating that
Average Delta E was "<5.0" for both sRGB and aRGB profiles (plots suggest
maximum "DeltaE*CIE94" of less than 3, average of 1 or so) using a Minolta
Color Analyzer CA210. It also shows gray-scale tracking and gamma curves,
but I find them hard to make something out of. Evidently, color temperature
is a constant 6500K for grey levels>25, but strays off into cooler values
for grey levels<25.
If it's in that mode when you measured it, and if the display is behaving
as it is indicated by the report, then the Spyder 3 reading of
8157K with DE 18.9 to daylight locus makes the Spyder look very bad :-(
There aren't any ccmx files for a Del27XX and Spyder 3, but there is one
for an HP wide gamut and Spyder 3. There wouldn't be much to loose
by using that with your instrument and seeing if the white point
comes up a bit closer to 6500K.
When my display offers a simulated "sRGB" mode (that from tests is judged as
fairly good), am I right that it is the only way for me to get sRGB
appearance from non-color-managed applications/OS-es?
Yes. Calibration can't move the primaries, whereas a matrix transform
can, and the display hardware will (presumably) do this in sRGB mode.
Since ArgyllCMS make
nice profiles that will not be used in that case, and the display
calibration only touches white-point and brightness (no front-panel 3x3
matrix input)? Further, as the display is native 8+2 bits, 12 bits
processing, while DVI is practically limited to 8 bits (displayport does 10
bits, possibly also with this screen but is not recommended by Dell due to
wake up from suspend quirks,
http://en.community.dell.com/support-forums/peripherals/f/3529/t/19339056.aspx),
this might avoid banding issues.
It depends on how much the calibration is doing. If the calibration curves
aren't making much adjustment, then the 8 bit limitation may not
be an issue. Calibration using display card VideoLUTs & Display Port 10 bit,
or display internal 12/14 bit precision is desirable if more extensive
calibration is being applied though.
How does ArgyllCMS relate to Madshis MadVR and "3DLUT"? I take it that its
massive 96MB LUT does an exhaustive lookup of every possible "rgb" input to
its corresponding "rgb" output, meaning that no parametric simplifications
have to be made (of course, regularization may come in handy anyways). But
is that approach more suited for movies and other material that adhere to
some agreed-upon standard, while editing photos in Lightroom/Photoshop is
more suited for the real-time color management inside those applications?
I'm not aware of the details, but it's all kind of pointless if the
basic information isn't precisely known. If the transformation is defined
precisely everywhere by a matrix and per channel curves, then you
may as well directly apply these. If the display behaviour doesn't
fit curves + matrix, then some other, better model is needed (what ?),
or a more general approach such as multi-dim. lookup tables needs to be used.
General lookup tables are limited by the practical issues of measuring
the display. It's not very practical to measure more than 5-10000 test
patches (and even then instrument and display drift can be a problem),
so what's the point of a 96MB lookup ? If smoothness of linearly interpolated
multi-dim. cLUTs is an issue, then there may be some point in upsampling
them a little to smooth the cell transitions, but I'd be a bit surprised
if a grid res. or more than 60 would make any difference, unless the
transformation is extreme.
What does Wide Gamut really, physically mean? Does it mean that the spectra
of the nominally "red", "green", "blue" primaries are sharper/narrower,
giving less overlap and thereby allowing more saturated colors?
Yes. Typical one/some of the primaries are a little purer == closer to
the spectrum locus. They may also move the red and/or blue a little closer
to the purple end, but there is a tradeoff with brightness, since our
eyes get less sensitive to extreme short & long wavelengths.
When this is
accomplished by swapping back-lighting, does it mean that the backlighting
consists of 3 narrow peaks (meaning that there is little excitation in the
regions where the panel "valves" might overlap)?
Yes. Typically with emissive displays there is no overlap between primary
colors, even for non-wideband displays.
2. They measure a lower black level than I do, leading to higher contrast
and perhaps gamma issues (?).
A lot of instruments aren't very accurate or stable near black.
In some simple comparisons I've done, I've seen extreme differences
between different colorimeter instruments, sometimes of the order of 10-20 DE
for saturated colors.
Graeme Gill.
Other related posts:
