Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!unix!quintus!arisia!sgi!shinobu!odin!odin.corp.sgi.com!portuesi
From: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Newsgroups: comp.sys.amiga
Subject: Re: Amiga and Image Processing: take 2
Message-ID: 
Date: 16 Aug 89 15:12:42 GMT
References: <3043@deimos.cis.ksu.edu> <120820@sun.Eng.Sun.COM> <822@abvax.UUCP>
Sender: news@odin.SGI.COM
Distribution: usa
Organization: Silicon Graphics, Inc., Mtn. View, CA
Lines: 54
In-reply-to: set@xanadu's message of 11 Aug 89 22:00:08 GMT


In article <822@abvax.UUCP> set@xanadu (Scott Townsend) writes:

   Does anyone know a quick way to go from bit-plane
   oriented to pixel oriented graphics data?  I'd like to play around at home on
   IFF images, but just doing a slew of ReadPixel() calls is awfully slow.

   (If that isn't clear, I'll try a different explanation: the Amiga stores all
   bit 0's next to each other in one plane, then all bit 1's, etc.  For image
   processing, you prefer all pixel value bits in one byte -- well, that's not
   too clear either, sorry)


I think what you're trying to say is that because the Amiga has a
bit-plane architecture, the data for each pixel can be stored in up to
six different memory addresses (the maximum number of bit planes the
Amiga chipset can currently display).  Thus, getting a single pixel
(the most common operation in image processing algorithms) from the
display can take up to six memory accesses on the Amiga.

As somebody else pointed out, high-end graphics hardware often has
some provision so that a pixel in a bit-plane oriented display may be
grabbed in one operation.  In fact, a recent issue of the _Amiga
Transactor_ contained a proposal for a revision of the Amiga display
hardware to provide this feature.

Anyway, it should be possible to achieve some of the savings of having
pixel-packed data on the Amiga by maintaining a pixel-packed copy of
the image in a memory buffer, and using that for performing image
transformations.  The result could be mapped back into bitplanes for
screen display.

The disadvantages of this approach are that it would cost much CPU to
convert an entire image from bit-plane to pixel-packed and vice-versa,
and each image would require twice as much memory (or more, depending
on your implementation) for processing.  On the plus side, this
approach would be a big win for image filters which must access each
pixel in the image more than once.  And if you are processing an image
with more color bandwidth than the hardware can display (such as an
8-bit monochrome or 24-bit color image), you have to keep a separate
buffer and use CPU cycles to downconvert the image for display anyway.

Finally, it may be possible to use the blitter chip to convert an
image from bit-plane to pixel-packed orientation very quickly.  The
disadvantage of this approach is that both versions of the image would
be forced to reside in CHIP memory in order for the blitter to convert
between them.  Designing blitter algorithms is not my specialty, so
I'll leave the dirty work to someone else.

				--M

--
Michael Portuesi	Silicon Graphics Computer Systems, Inc.
			portuesi@SGI.COM