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