Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sm.unisys.com!aero!venera.isi.edu!raveling
From: raveling@vaxb.isi.edu (Paul Raveling)
Newsgroups: comp.windows.x
Subject: Re: Small proposals for the next round of protocol changes [X12?]
Message-ID: <6150@venera.isi.edu>
Date: 26 Aug 88 03:49:26 GMT
References: <880818-131820-7122@Xerox>
Sender: news@venera.isi.edu
Reply-To: raveling@vaxb.isi.edu (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 37

In article <880818-131820-7122@Xerox> jacobi.pa@XEROX.COM writes:
>
>Some small proposals for the next round of protocol changes [X12?]

	Here's another modest suggestion, should there ever be
	an X12, or whatever...

	Small Color structures -- 8 bits per RGB component, and
	maybe even per pixel.


	Image quality improves measurably as the number of colors
	available increases, but to a human observer it takes
	careful study to find a difference past about 6 bits of
	resolution.  Even 5 bits is pretty good.
	
	For this reason plus economics, I believe 8 bits is
	a reasonable practical value for the maximum resolution
	anyone is likely to build into display hardware.  It's
	less clear that 8 bits is sufficient as a pixel index,
	but 16 should be practical.

	Some of our image processing utilities need one copy of
	an image which would best be represented by a Color structure
	and another which can be mainly an array of pixel values.
	When the image size is around a megapixel, using the current
	Color structure can generate a couple malloc's for a total
	pushing 15 megabytes in two blocks.  Not many of our workstations
	can handle that sort of memory load.
	
	A Colors and pixels that are smaller by a factor of 2
	would be welcome.


---------------------
Paul Raveling
Raveling@vaxb.isi.edu