Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!sun-barr!newstop!sun!falk
From: falk@sun.Eng.Sun.COM (Ed Falk)
Newsgroups: comp.graphics
Subject: Re: Image file format discussion
Message-ID: <126656@sun.Eng.Sun.COM>
Date: 21 Oct 89 01:28:57 GMT
References: <1198@clinet.FI> <390039@hpfcdq.HP.COM> <4608@mentor.cc.purdue.edu> <6040@pitt.UUCP>
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 59

> _Big-endian vs. Little-endian_:  does 255 represent white or black?

White.  I've never seen an exception, although I suppose there might be.
I think it would be simpler to reverse the numbers when writing your files
than to get the whole world to accept a new image attribute.

> _Primary colors_:  the wavelengths of the (R, G, and B) primaries used
> in representing the image.  Usually the NTSC primaries are used, but
> some devices such as color printers may use other primaries.
> Furthermore, the actual color of the pigments may vary from monitor to
> monitor, and if the information is known for a particular monitor then
> color correction can be performed.  Primary color information is is
> essential in matching colors between devices with different primaries.
> [See Roy Hall's book "Illumination and Color in Computer Generated
> Imagery."]

I don't see how you're going to match colors between systems with different
primaries, but I suppose if you're going to go to all that trouble,
then you might as well find out what the primaries are on the system that
produced the image and assume that's what the rgb values represent.

> _Gamma correction factor_:  Monitors, video cameras, and other
> equipment vary in their "gamma correction" value.  Typically, the
> brightness output of a monitor is not linear with the input value, but
> exponential.  It typically depends on the input as the function
> 
> lookup value = intensity ^ (1/gamma)
> 
> It is possible to perform gamma correction before storing the data in
> a standard file format, but much information is lost.  For a monitor
> with gamma 2.2 and linear input, only about 190 of the 255 different
> possible output values can be used for an 8-bit image [from Hall].

Well, since gamma varies from monitor to monitor (depending on manufacture,
how it's adjusted and how bright the room lights are where the monitor
sits), there's no point in storing the information in the raster file.
The ideal situation would be for every raster file to represtent intensities,
and for every viewing program to know the gamma for the monitor it's
being run on (how? /etc/gamma or something?) and ajust accordingly.

In truth, most images were generated by someone who "tweaked" the values
on their own system until they looked "good", and then wrote out a
rasterfile.  This means that every rasterfile contains an implicit
crude gamma correction built in.  It would be nice if everybody knew
the gamma of their own monitor and reverse-corrected when they wrote
out the rasterfile, but in practice, this never happens.  In fact, one
of the secrets to generating a good 1-bit-dithered image from an 8-bit
image is reversing the gamma correction in the 8-bit raster file
before dithering.


I suppose if you *really* want to store this kind of information in
raster files, you could have new tags added to TIFF.

-- 
		-ed falk, sun microsystems, sun!falk, falk@sun.com

  "If you wrapped yourself in the flag like George Bush does, you'd
  be worried about flag-burning too"