Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!uwvax!astroatc!nicmad!madnix!perry
From: perry@madnix.UUCP (Perry Kivolowitz)
Newsgroups: comp.sys.amiga
Subject: Re: The Art Department and Memory
Message-ID: <1615@madnix.UUCP>
Date: 10 Nov 90 02:18:10 GMT
References: <1990Oct25.193715.8382@hayes.ims.alaska.edu> <1990Oct25.224025.7029@ux1.cso.uiuc.edu> <1611@madnix.UUCP> <1990Nov5.053442.4010@uokmax.ecn.uoknor.edu>
Reply-To: perry@madnix.UUCP (Perry Kivolowitz)
Organization: ASDG Incorporated
Lines: 22

In article <1990Nov5.053442.4010@uokmax.ecn.uoknor.edu> drtiller@uokmax.ecn.uoknor.edu (Donald Richard Tillery Jr) writes:
>That 3.75 bytes per pixel is a pain!  I have 5 megs (1 meg chip, 4 fast) and
>I cannot load in a 1024x1024x256color picture.  My calculations tell me
>that that is 1Meg pixels.  At 24 bits per pixel that is 3 megs.  However,
>3.75 megs (even if I run ONLY TAD) is not available so I can't do anything
>with these GIFs.  Isn't there some work around for this?

The 3.75 is derived from 3 (for 24 bit-planes/8 bits-per-byte) for storing
the raw image data at its fullest resolution plus .75 (6 bit-planes/8 bits-per-
byte) for storing an Amiga displayable rendered image area.

Just a little more contiguous fast ram would do the trick. Unfortunately,
there's no other work around and still get TAD's quality/speed. IE: you
can store less image data (and get speed but less quality) or page from
disk (get quality if the package is otherwise as good as TAD, take a big 
speed hit). 


-- 
Perry Kivolowitz, ASDG Inc. ``We look for things. Things that make us go.''
	UUCP:  {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry
	CIS:   76004,1765 PLINK: pk-asdg