ctice@pbs.org (03/27/91)
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
rberlin@birdlandEng.Sun.COM (Rich Berlin) (03/27/91)
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