[argyllcms] Re: Bad measurements & white point calibration with Argyll 0.7b7 and GretagMacbeth i1Display 2
- From: Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 11 Jan 2008 01:52:30 +0900
Gerhard Fuernkranz wrote:
> Craig Ringer wrote:
>> Among other things it includes information on setting the 14-bit internal
>> RGB LUT on their monitors,
>
> Does this mean that there is programming information for the bare
> hardware available? Or is this hidden behind a closed source library?
In brief: The docs are quite enough information without the library, and
the library doesn't seek to hide anything.
There is enough information in the header file and PDF documentation to
control the display fairly well without using the binary library. I've
written a little win32 utility that plays with the RGB gains, the
brightness level, and the Eizo-specific control panel lock flag; it
works fine without using any Eizo supplied binaries or code. I actually
had the gains and brightness working before getting the documentation
from Eizo. The control protocol is an extension of the USB HID Monitor
spec that's available at :
http://www.usb.org/developers/devclass_docs/usbmon10.pdf
so the use of that plus a bit of snooping the USB bus while using the
Eizo display control applet on Windows was enough to do some of the basics.
However, the Eizo panels only implement some of the HID Monitor spec,
and have a *lot* of functionality not defined by the spec. There are
also a few feature reports that're much like those defined in the spec
but not mapped to the normal usage code. Some of it can be figured out
by bus snooping and by sending HID reports to various IDs ("I wonder
what setting this affects... oh, the 'expensive smoke' control...") but
much of it was pretty opaque to me without the documentation. Then
again, I'm very new to USB, HID, etc.
The documentation that comes with the SDK covers the usage of all the
report descriptions, parameters, enumerations, etc that appear to exist
according to the device's HID descriptors. Along with the header file
that provides the actual HID report codes and enumeration IDs needed to
communicate with the monitor there seems to be plenty of information,
and I had no problems getting basic controls working.
The Eizo header does list report IDs rather than usage codes. That means
that you can use info in the header without having to parse the HID
descriptor tables to map usage codes to report IDs; however, it also
means that your messages won't work with other USB HID monitors since
they may use different report IDs for the same usage codes. It's not
hard to dump the HID table of an Eizo monitor and use that to map back
to the usage codes though, and many of the codes will be vendor specific
anyway.
Most of the controls are simple get/set feature reports that're pretty
easy to use from userspace without having to install a driver or claim
exclusive control of the device - at least under Windows and Mac OS X. I
haven't got it working with hiddev ioctls from userspace under Linux
yet. Given the issues I've seen reported, and had, with the Linux hiddev
driver when using feature reports it's possible it might be necessary to
blacklist the device to hide it from the hiddev driver then claim direct
access using libusb under Linux instead. That's unfortunate since it
prevents other apps (vendor display control applets etc) from being able
to use the device like they can on win32 and Mac OS X, but on the other
hand it should work on more UNIX flavours. The libusb based libhid will
probably make it a bit nicer than using raw libusb would be.
Some of the controls - like the monitor internal LUT setup - are a bit
more complex than just a get/set feature report but they can still be
done with HID in userspace. I haven't done anything with the LUT control
features etc yet but the documentation describes them pretty well.
The Eizo library uses libusb on *nix, and in fact doesn't seem to be too
much more than a libusb wrapper with some code for discovering &
enumerating Eizo monitors in it. There does not appear to be any effort
being made to hide the protocol using the library. Given that it uses
USB HID it'd be somewhat pointless anyway, since many of the basic
controls can be easily figured out using bus snooping and the more
complex ones probably wouldn't slow down anyone experienced in reverse
engineering and USB protocols for long.
The documentation makes it all a lot nicer and a lot easier though, so
I'm really hoping Eizo will give the OK to put it up somewhere or will
publish it for public access themselves. Google can't find any of the
major definition names etc so it doesn't appear to be up in any
Google-reachable corner of their site already.
I started playing around with this some time ago as I was interested in
setting up automatic feedback from measurement instrument to display, so
the user could enter their desired settings then place the measurement
instrument on the screen and walk away. I was also curious about the
possibility of using the higher bit depth LUT in the display for
calibration instead of the graphics card LUT, since I understand that's
what some high end calibration tools do. The automatic display
adjustment is something I'm hoping to have the time and mental wattage
to try to add to lprof at some point (though the last week hasn't been
promising there).
I'll poke Eizo again and try to find out more about the status of the
documentation.
--
Craig Ringer
Other related posts:
