mcgowan@nisc.nyser.net (Craig McGowan) (09/20/89)
Would like to move digitized images from our AppleScanner to monochrome Suns running X. I have tried two approaches unsuccessfully: a) the Xbitmap program from the sumex archives, b) using the tiff2fbm foo.tiff | fbnorm | fbhalf -P | pbmtoxbm pipeline. "A" creates bitmaps which can't be read by X under certain circumstances and "B" sometimes munges the bitmap so that it looks funny. Has anyone out there got another idea? -- Craig McGowan NYSERNet, Inc.
earleh@eleazar.dartmouth.edu (Earle R. Horton) (09/21/89)
In article <1366@nyser> mcgowan@nisc.nyser.net (Craig McGowan) writes: > >Would like to move digitized images from our AppleScanner to >monochrome Suns running X. I have tried two approaches >unsuccessfully: > >a) the Xbitmap program from the sumex archives, > >b) using the tiff2fbm foo.tiff | fbnorm | fbhalf -P | pbmtoxbm >pipeline. > >"A" creates bitmaps which can't be read by X under certain >circumstances and "B" sometimes munges the bitmap so that it looks >funny. > >Has anyone out there got another idea? The Xbitmap program source is on sumex. The problem with Xbitmap is that it doesn't check the bitmap dimensions for validity. It merely takes the bitmap dimensions from the picture frame rectangle of the input 'PICT' file. If this rectangle has a width which does not imply an even number of bytes, then X rejects the file because the header specifies a nonsensical width. There are two ways around this problem. One is to use only 'PICT' files where the picture frame has a sensible width, i.e. divisible by 16. The other is to get the source from sumex, and fix it. All you have to do is to make Xbitmap write out files to specify a bitmap width which is equal to the width of the internal offsreen BitMap where the image is buffered in memory. I could fix this, but I am in thesis-writing mode right now and can't afford the time. Earle R. Horton