LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
December 2006
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2006.12.06 01:58 "Re: Grayscale, or is it?", by Graeme Gill
Glenn Widener wrote: > We (SwiftView) used to obey the spec regarding a default gamma of 2.2. But we > found no one else that does, so we can't either, and we changed the default to a > straight linear device RGB. "No one else" includes at least.Microsoft Office > Document Imaging and Paint Shop Pro 6. There seems to be lots of confusion involving the words "linear" and "gamma" in these discussions. To me, the sections of the spec. that Joris quoted means that grey should not be gamma encoded (ie. it can't be fed straight into a CRT monochrome display), but has to be linear light encoded, in contrast to the RGB data which does have a default gamma of 2.2 You're paragraph above seems very confusing to me. You're saying you obeyed the spec. default gamma of 2.2, except that from what Joris quoted, there is no default gamma of 2.2 for grey in the spec.! Then you say you switched to straight linear, but then you say you switched to device RGB - which contradict each other. "straight linear" I interpret to mean "linear light", ie. gamma = 1. Typical "device RGB" is sRGB like, and is not linear, it has a gamma somewhere around 2.2, which is what Microsoft Office etc. use. Either we're interpreting "straight", "linear" and "gamma" differently, or perhaps you are confusing the processing applied, with the state of encoding ? > Linear means literally read, write and send the values to your display unchanged > - "linear device values". If you don't know what the correction is, or haven't > been told, don't do any. It's very confusing to to talk about processing steps. Processing steps get inverted when you change the direction you're going, or change the destination encoding you are transforming to, while an encoding state is a constant frame of reference, from which you can figure out what processing steps to use. So while you might use "linear processing" to transport gamma 2.2 encoded grey value to a device that expect gamma 2.2 encoded grey values, it doesn't make the the encoding "linear". > The standard conversion from RGB to gray, documented in the textbooks, is grey > level = .33R+.5G+.17B. So a unitary conversion back to RGB is fine. And of course this equation is acknowledged to be wrong - you can't combine gamma encoded values like this to give a correct greyscale. To do it properly, you have to turn the values into linear light encoding, then weighted sum them, and perhaps re-encode with gamma again. The NTSC system adopted the above simply for expedience - it's tricky to decode into linear light and back again using vacuum tubes - so they compromised on the monochrome reproduction. If you have a full characterization of your grey space (say an ICC profile that gives a mapping from device space to CIE values), then you can use (and may or may not want to use) other than a unitary conversion to a 3 color space. If the grey process gave (for instance) a sepia response, then for proofing you may want to reproduce the sepia tones in RGB. Of course I agree that most of the time something simpler is expected, so converting to the correct gamma encoding and then duplicating is channel is the usual process. Graeme Gill.