🚀 go-pugleaf

In article <9002192154.AA01862@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
>There is some discussion going on in the ximage mailing list about gamma
>correction and where it should be done.  Saying it should *always* be done
>isn't necessarily the right answer either.  The real problem I think, for most
>applications, stems from the use of an inherently device-dependent color model
>(RGB) as the only interface.  A device independent color model (e.g. the HVC
>model that Tektronix presented at a past X conference) would be a better
>solution than introducing gamma correction.

It *is* always done.  Currently what happens is that people choose
colors that look good on the monitor they are using.  So the colors
in places like rgb.txt have been manually corrected for somebody's
monitor.  Since monitors don't differ too greatly, people don't notice.

That is until they try to display image data, whether scanned or synthetic.
Applications that care end up having to guess the monitor characteristics
and do the correction themselves.

I don't agree that a new color model is required.  
All that's needed are some correction tables (r, g, and b per screen) and 
a way for applications that care to specify DoCorrection to XStoreColors.
That would handle most things quite well, without breaking any existing
clients.

If you try to do really high quality correction, like color matching for
the print world, I doubt you will be able to satisfy everybody.  
For applications that need that level of quality, some esoteric 
Queryable monitor characteristics like white-point should help them out. 

Dan McCoy  ...!ucbvax!pixar!mccoy

(Sorry if you think that ximage is the place for this kind of stuff,
things have gotten pretty quiet there.  There were only two of us making
up that discussion.)