Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!birdland!rberlin
From: rberlin@birdlandEng.Sun.COM (Rich Berlin)
Newsgroups: comp.lang.postscript
Subject: Re: Image operator anomaly?
Message-ID: <10537@exodus.Eng.Sun.COM>
Date: 27 Mar 91 03:00:31 GMT
References: <1991Mar26.171046.12170@pbs.org>
Sender: news@exodus.Eng.Sun.COM
Reply-To: rberlin@Eng.Sun.COM
Organization: Sun Microsystems
Lines: 32

In article <1991Mar26.171046.12170@pbs.org>, ctice@pbs.org writes:
|> 
|> Hello!  I have recently run into what appears to be a strange anomaly in a bit
|> of PostScript code, and I was wondering if anyone out there has seen anything
|> similar or could explain what is going on.  The problem I am having is with the
|> PostScript IMAGE operator.  I took a photograph and scanned it.  I then used
|> Adobe Photoshop (tm) to translate the scanned image into an EPS file.  When I
|> opened the EPS file to look at what was done the EPS code didn't make sense. 
|> It said that my scanned data was 497 samples wide, 673 samples high, with one
|> bit per sample.  So far so good.  But the string it was using to read in the
|> hex data was of size 63.  Now according to everything I have read and/or been
|> taught, the width x height x bits per sample must be evenly divisible by the
|> string size.  496 * 673 * 1 = 344,481.   344,481 / 63 = 5309.2222...  So it
|> would seem that the code as generated by Photoshop (tm) shouldn't work. 
|> However it works like a charm.  Even more confusing, if I change the string
|> size to 497, which DOES divide evenly into 497*673, nothing prints out at all. 
|> Could somebody explain what is going on?  PLEASE?
|> 
|> 						Caroline Tice
|> 						PBS


The image operator expects each scanline of the image to be padded to
a byte boundary.  Your 497-sample wide image is only 1-bit per sample
and therefore has to be padded to the nearest byte.  A single scanline
thus requires

   (497 + 7) / 8 = 63 

bytes of data.  Hence the magic number 63.

-- Rich