🚀 go-pugleaf

	I am working with an art professor at Purdue University who wants to
integrate some of his artwork with AutoCad.  He has a Targa high res graphics
card and an optical digitizer.  Between the two, he is capable of producing
color images with near photographic quality (rgb, 400X512, 32000 colors).  
His goal is to take a picture file generated by the targa imaging system, and
after a little manipulation, load it into AutoCad representing each pixel as a
block.  Because of the large size of the targa image file, we use the targa 
software to first grey the image (eliminating color) and then "mossaic" the 
image so that the screen resolution is effectively quartered.  After that step
we read the resulting picture file in quarters to further reduce the output
file size.  The result is an output file representing a selected quadrant 
of the original digitized image at a quarter resolution.   The number of blocks
in the resultant file is 50 X 256 = 12800.  Is this a large number of blocks for
AutoCad?

	We tried two different AutoCad input file formats.  The .DXF format 
and script (.SCR) file.  Both of these formats cause the PC to hang, or to 
produce an "Out of ram" error message.  This particular PC is a 286 machine 
running with about 2 MBytes of memory.  Unfortunately this version of AutoCad
only recognizes the bottom 640K.  AutoCad hangs after reading approximately 
5000 block inserts (this is only ~40% of the input file).  Does anyone know 
what kind of memory overhead is associated with inserted blocks?

	If the problem is not AutoCad block sizes, it may be in the hardware.
The PC tends to be a bit brain damaged and does not operate properly at 10MHz
speed.  In fact, AutoCad blows up with a "parity error" if it is run at 
anything higher than 6MHz.

	If anyone has any detailed information about AutoCad (internal block
representations) or any ideas please let my know.




				Thanks

				Colin Jenkins

				ihnp4!pur-ee!k.cc.purdue.edu!ag0