EDID decoding in libXrandr?
Hal V. Engel
hvengel at astound.net
Mon Nov 19 12:09:12 PST 2007
On Monday 19 November 2007 11:10:51 Kai-Uwe Behrmann wrote:
> Why not reply to the xorg list? I think they should see our conversion to
> better understand the interessts we colour people have there.
Sorry that is what I intended to do. Must have pushed the wrong button.
> I am afraid I have to switch to non digest mode to not break the
> discussion threads. Hope then my messages will be more readable.
> Am 19.11.07, 10:37 -0800 schrieb Hal V. Engel:
> > On Monday 19 November 2007 06:46:40 you wrote:
> > > > Date: Sun, 18 Nov 2007 09:29:30 -0800
> > > > From: "Hal V. Engel" <hvengel at astound.net>
> > > > On Sunday 18 November 2007 01:00:53 Kai-Uwe Behrmann wrote:
> > > > snip
> > > >
> > > > > Not shure if the colorimetry information will make sense for some
> > > > > people. I mean the RGB primaries and the witepoint from position 25
> > > > > till 34 and gamma in 23.
> > > > > As I see, this information is dangerous for broken monitor EDID's
> > > > > and of not much value for most of the others. Still it is there.
> > > >
> > > > Assuming that this info is (partly) valid for cases were the EDID is
> > > > not broken then this could be useful. For example LProfs visually
> > > > based monitor profiler could use the RGB primaries and maybe the
> > > > whitepoint information. But that also means that as a consumer of
> > > > this information I also need to be able to query X as to how broken
> > > > EDID is for the device in question.
> > >
> > > Agreed with the EDID borken status to be asked first before use. Just
> > > the EDID colorimetry information may be broken in that sense that most
> > > monitor manufacturers, or who else provides the EDID blob, dont much
> > > care about that information. That said, even in a otherwise valid EDID
> > > block can stand garbage or simply sRGB coordinates in the colorimetry
> > > section of EDID.
> > > That may be the reason why it is not much used on other platforms. I
> > > remember a small little application, which parsed the EDID block to
> > > create a profile.
> > > ... ddc2xdccc.c Interesstingly it creates a deprecated XDCCC block.
> > >
> > > If you can render say 90% of the monitors have a better than nothing
> > > colorimetry in EDID, then the according buttons in LProf may have
> > > technical value. At least you should check for swapping and non
> > > relevant values.
> > >
> > > Last but not least some users may be irritated to get the inbuild
> > > colorimetry straight from the monitor without a mesurement device -
> > > huh. Will be difficult to explain later why they should by a
> > > colorimeter, which may cost more than the complete monitor if they have
> > > the inbuild data already ;-)
> > >
> > >
> > > kind regards
> > > Kai-Uwe Behrmann
> > Unless the monitor has perfect response curves and gray balance, which is
> > not very likely, we need more than the primaries and white point to do
> > calibration and profiling correctly. Using a color meter or
> > spectrophotometer should always be preferred to using the values supplied
> > by the monitor vendor in the EDID even if the EDID data was totally
> > correct when the monitor left the factory. This is the case because it
> > is possible to compensate for nonlinearities in the the response curves
> > of the device when using a measurement device. In addition, monitors
> > change over time and as the monitor gets older it's colorimetric data
> > changes while the EDID will not change to reflect this. For those
> > users who can not afford a meter having good info about the primaries and
> > white point gets us part of the way there at no cost. So this would be a
> > "poor mans" solution but it is far from optimal.
> > Color meters are now fairly inexpensive and only very low end monitors
> > are less costly than some current measurement hardware. For example, you
> > can purchase X-Rite Huey meters on eBay for about $50 plus shipping and
> > these are now supported on X11 systems by both LProf (CVS) and ArgyllCMS
> > (0.70 beta 7). The Huey has some minor issues but in my testing so far I
> > have been pleased with the results. I do, however, prefer the X-Rite
> > EyeOne Display 2/Lt meters which can be purchased for about $130 (some
> > times less) if you shop around. Users should stay away from the
> > ColorVision line of devices because the vendor has a very bad attitude
> > toward the OSS community.
> Shame over Ross who bought one device from ColorVision despite the non
> moralic, reads open source friendly, behaviour of that company ;-)
> Indeed I am really happy that we get specs and the some time ago big
> barrier seems to break. ColorVision is can now be considered more a
We are not getting specs from any of these companies and in every case their
relationship with the OSS community is less than ideal. But at least the
X-Rite folks are talking to us and are trying to understand how to work with
us even if they have a ways to go. ColorVision does not even try to hide
their distain for us. Like I said a VERY bad attitude.
> The next target would be the monitor inside LUT. What does you think?
We have looked a little at the Ezio LCD monitors which appear to expose the
monitors internal LUT via the USB HID monitor controls. One of our
developers has the Ezio USB HID SDK (which really just documents the
interface) and Ezio seems to be fairly open about this and appears to be
willing to work with the OSS community. So it is possible that this could
be made to work at least for some monitors since this would not be much
different from what we currently do to calibrate the dispaly using the video
card gamma tables. But I don't know if it will be possible to generalize
this to work for more than a few vendors monitors.
> > As a side note there was one freeware (or was it shareware) Windows
> > application available at one point that used the EDID colorimetric data
> > to create monitor profiles.
> Interresting. What was the over all experience with this application?
I never used it and I don't know anyone who has so I can't comment on it
beyond the fact that it existed.
> > Hal
openicc mailing list
openicc at lists.freedesktop.org
More information about the xorg