[comp.graphics] Image file format discussion

planting@hobbes.cs.pittsburgh.edu (Dr. Harry Plantinga) (10/20/89)

In article <4608@mentor.cc.purdue.edu> ahg@mentor.cc.purdue.edu (Allen Braunsdorf) writes:

>GIF	A format for storing images with color look up tables.  No aspect
>	ratio is saved, so fidelity cannot be insured.  The file consists
>	of a header of fixed fields, an optional global color map,
>	and one or more images (which each have a header and optional
>	local color map).  The format is extensible through ! blocks.  
>
>IFF	A general interchange format for data.  The part you want to look
>	at is the FORM ILBM.  This is a fairly simple digital image
>	structure that describes the attributes of an image and how
>	to decipher it and then has the image itself.  The format is
>	extensible by the addition of chunks.
>
>TIFF	A very flexible image storage format.  Files contain a small header
>	and then a directory of tags.  These tags describe attributes
>	of the image.  By adding tags, the format can be extended.

There is other information that should be stored with images but which
I have not heard anyone mention.

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

_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."]

_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].

=================

Is there other information that should be stored with an image?

Is there a file format that stores this information?

If not, perhaps this group should define standard extension to one of
the existing file formats for storing this information.


-Harry Plantinga
planting@cs.pitt.edu

falk@sun.Eng.Sun.COM (Ed Falk) (10/21/89)

> _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"

chris@well.UUCP (Chris Sears) (10/22/89)

In article <6040@pitt.UUCP>, planting@hobbes.cs.pittsburgh.edu (Dr. Harry Plantinga) writes:
> In article <4608@mentor.cc.purdue.edu> ahg@mentor.cc.purdue.edu (Allen Braunsdorf) writes:
> 
> There is other information that should be stored with images but which
> I have not heard anyone mention.
> 
> _Big-endian vs. Little-endian_:  does 255 represent white or black?

By this do you mean byte ordering.  TIFF supports both Intel and Motorola
byte ordering.  "does 255 represent white or black?",  This is called
Photometric Interpretation in TIFF parlance.

> 
> _Primary colors_:  the wavelengths of the (R, G, and B) primaries used
> 
> _Gamma correction factor_:  Monitors, video cameras, and other

TIFF tags for primary chromaticities, white point are available.
For gamma, color response curves describe any sort of companding function
as a set of 3 16-bit lookup tables.

"Internal" compression schemes are also available.  The full TIFF 5.0
specification is available from Aldus.

And, best of all, an excellent public domain TIFF library written by
Sam Leffler is available via FTP from ucbvax.berkeley.edu.  It is very
easy to use and extend.

--Chris

jtc@tessera.uucp (J.T. Conklin) (10/22/89)

In article <6040@pitt.UUCP> planting@cs.pitt.edu writes:
>There is other information that should be stored with images but which
>I have not heard anyone mention.

You are in luck.  Image colorimetry information was added to the TIFF
standard as of TIFF 5.0 (8/8/88).

>_Big-endian vs. Little-endian_:
    Set by GreyResponseCurve for bilevel and greyscale, and ColorMap
    for palette color images.  RGB is defined such that 0 represents
    minimum intensity.

>_Primary colors_:
    Set by TIFF's PrimaryChromaticities tag

>_Gamma correction factor_:
    Set by TIFF's ColorResponseCurves tag

    --jtc


-- 
J.T. Conklin
	...!{ubc-cs,uunet}!van-bc!tessera!jtc

ralph@atrp.mit.edu (Ralph L. Vinciguerra) (10/24/89)

The need for another image file format was mentioned since more
descriptive information could be sent with images. I recommend another
look at the IFF format. It is a structured and extensible format which
allows things like "properties". Thus, no new image format would be needed
to represent all types of image gathering and reproduction parameters.

The documentation is available from many sources, and the standard is a
dynamically evolving one since it's extensible and also handles things
like sound, music, 2 and 3 D drawings, etc.. One company is
acting as a clearing house for new data types and compatibility.
Also, many source code examples are available for reading and writing
the format.

I have a US Mail address from which one can order documentation.
Send me e-mail if you need it.