	Usage of Color Maps in GIF, and Recommendations (V 2.0)
 
		by Larry Brennan, 73327,3452
 
	Since an update of the GIF87a is contemplated, and some recent msgs on 
the Board have indicated misunderstandings of the significance of the
Global Header information described as CR ( color resolution ) and Pixel,
please indulge me in my attempt to clarify.  Then I'll recommend a slight 
change in the Standard and several changes in the practices of encoding
and decoding GIF messages.  The purpose is to increase the information
content of the data, while reducing the redundant content of the message.
 
	The CR value represents the information value of the originator's
selection of colors to represent the subject, as limited by the originator's
machine and choice of mode.  The originator might have a choice field of,
say, 64d (EGA), or 4Kd (Amiga), or 16Md (VGA), and that information is
pertinent to the decoder's choices of data for use of the target machine.
The Pixel information represents the maximum palette array available to
the originator's machine or mode, also useful information as to the limitations
of the encoded message.
 
	The 87a definition of Pixel usage unnecessarily requires a color map 
content of the maximum number of available palette indices, whether they
are used or not, and usage of all of the indices is actually not common
in practice.  I heartily endorse the restriction of color map requirements
to the actual number used by the originator, with a few usage caveats as
described below.
 
	The suggested usage refinements suggested are almost all at the encoder
end of the translation for transmission, so the extra time and effort called
for is not as critical as at the decoder end, where speed is more valued.
My first plea is for the elimination of redundant hue choices occupying
multiple palette indexes ( very common ).  The encoder can
easily do this, and the decode process is simplified.  The next step
would be to substitute NULL (0,0,0 for R,G,B) hue values for any palette indexes
not actually used.  Again a simple encoder process making the decoder's
life easier ( see CNTGIF & GIFDMP for  methods).  Next, reassign all used hue
codes into the lowest palette indexes and delete all NULL values (with two
exceptions) from the color map.  The exceptions are palette index 0, reserved
for a useable (black) NULL value which also serves as a start delimiter for the
color map, and another NULL value as an end delimiter for the
condensed map.  Note that the information content is the same as before the 
encoding and reorganization.  Now, to increase the useful information content,
arrange the non-zero hues into palette indexes in reverse order of actual
employment in the particular frame.  The decoder can address the translation
of the original color map to the target machine's color map in the priority of
actual usage in this specific frame, with no cost in time and with no clutter
of either redundant or unused definitions.  Note also that existant GIF files
are still fully decodable without modification.
 
	It is my view that at this point the decoder should carry
some of the load and eliminate any hue redundancies in the target's map
after translation, and also reassign the useful hues to the lower palette
indices.  I don't sense a value to ordering the hue assignments by usage
prevalence, but it would make for a still cleaner end product.
 
	So my recommended changes are quite minimal by themselves, but |+^|result in a cleaner, neater, product which will be more easily upgrade
for future needs and increase the useful information content of the product
with little trouble or hassle now, and invisibly to the casual user.
 
	Thanks for the use of the Hall.  Larry Brennan.
 
    
 
   
 
 
 
 