Simon Kirby wrote:
Brightness loss: Only if I stray from the native white point, right?
Resolution: Yes, I see this, especially with 8 bit LUTs. :) Do video cards support 16 bit value LUTs at all these days? (eg: is this possibly an X limitation within Linux?)
Once upon a time, video systems used to support more than 16 bit entries in their Video LUTs, but apparently with the take-over of the graphics hardware industry by the "games" cards, this was lost. The Operating System API's permit up to 16 bit entries (which Argyll will make use of), but little or no hardware actually implements it. Anything using DVI is almost certainly limited to 8 bits by the DVI signalling conventions.
The main issue right now is that Linux has poor support for profiles. Web browsing, GTK, etc., mostly all do not make use of them. Only a fewapplications watch the attribute which "xicc" sets, and typically become very slow when they do.
There's no reason they should become slow, if they use a decent approach to color management.
I should note that I just tried beta7 (as opposed to beta6), and the output is now such that 0,0,0 black output from video card LUT is still 0,0,0. Did something change wrt this in beta7? The output is now:
There were a number of changes, but I wouldn't have thought this would have changed.
0.0000 0.018335 0.011353 0.010989 3.9216e-03 0.023509 0.016135 0.016037 7.8431e-03 0.028616 0.020859 0.021008 It is my understanding that this translates to 8-bit output integers of: 0: 0 0 0 1: 1 0 0 2: 1 1 1
Hmm. No. more like: 0: 5 3 3 1: 6 4 4 but you can't judge on the numbers, since many systems will have a "flat spot" from zero, where nothing changes until the levels reach some threshold. Naturally the calibration should start at the threshold, to avoid the flat spot. As I hinted, there are some issues with Beta7 in that if the white point changes during the run (due to drift, or inaccuracy in determining whether the white point fits within the gamut), the black point gets shifted as well, which it probably shouldn't. If you'd like to try this fix out, I've put an x86 Linux version of dispwin at <http://www.argyllcms.com/dispwin_x86_Linux.zip> that attempts to fix the issue you noticed. (You may have to "chmod +x dispwin_b8" after unziping it).
I attached the whole .cal file, as generated with: dispcal -K -m -g2.2 -k0.0 -yl -qu -v benq_native_b7 Note that with "-qu", I cannot actually see a visible patch in the first patch until patch number 9. I don't think this is because it is too dark, but because rounding or otherwise is resulting in the output still being RGB 0,0,0.
Note that "u" in -qu stands for: "unbelievably ultra slow" "untested and unverified" "uselessly excessive" :-) Unless there is a specific reason to do something else, I'd recommend that everyone stick to -ql, -qm, or -qh. The reason -qm is the default, is that it's generally the right choice. -qu exists only to be able to prove it is not needed.
Hmm. Yes, I was assuming that LCDs (especially compared with CRTs) would be perfectly additive.
Given that some of them have circuitry designed to make them look like an sRGB CRT (including 3D lookup tables), this can be far from the truth. The cheaper displays a probably close to additive though, I guess. Graeme Gill.