Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!adobe!heaven!glenn
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: A generic image data acquisition procedure. How ?
Keywords: image
Message-ID: <335@heaven.woodside.ca.us>
Date: 2 Dec 90 00:00:12 GMT
References: <1990Nov20.215152.1365@sti.fi>
Reply-To: glenn@heaven.woodside.ca.us (Glenn Reid)
Organization: RightBrain Software, Woodside, CA
Lines: 53

In article <1990Nov20.215152.1365@sti.fi> ttl@sti.fi (Timo Lehtinen) writes:
>
>On page 126, the green books states:
>
>"The data acquisition procedure used in a particular instance depends
>upon the amount and nature of the data making up the image."
>
>I understand this is also true for the length of the DataString used
>i.e. it has to match the length of the image in question.
>
>Now, lets say my file has tens or hundreds of bitmaps/images. Is there
>really no way to write a general purpose proc for data acquisition so
>that I merely would need to specify the width, length, depth and matrix
>for the image and then execute this generic image-display proc which
>would read the data as printable hex from currentfile ?  Seems like
>a really stupid limitation so I believe there must be a way...

The basic example for "image" in the red book is appropriately generic.
It looks like this:

	{ currentfile picstr readhexstring pop }

You can't get much more generic than that.  The "picstr" needs to be
defined slightly differently each time, but you already have to specify
the width, length, depth, and matrix anyway, so this is lost in the
noise.

You might try something like this:

/im	% width height bits matrix buffsize im
{ %def
    save
	/picstr exch string def
	{ currentfile picstr readhexstring pop } bind
	image
    restore
} bind def

80 200 8 [100 0 0 -200 0 200] 10 im

Then all your invocations will be exactly as you require; you only
need to pass one more argument, "buffsize", which will basically be
the width of the image divided by the bits/sample value.  Yes, you
could do this in the PostScript code, but it's easier and faster to
generate it from the App.

Anyway, the point is that even though in the green book it is
suggested that you can improve the efficiency of an image proc by
adjusting it to the data in some useful way, the standard proc
mentioned above already is perfectly generic and perfectly suitable
for any size image.

Glenn Reid


Brought to you by Super Global Mega Corp .com