Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!elroy!cit-vax!ucla-cs!zen!ucbvax!ucdavis!egg-id!llh From: llh@egg-id.UUCP Newsgroups: comp.graphics Subject: Re: Data Compression Message-ID: <457@egg-id.UUCP> Date: Thu, 19-Nov-87 17:08:39 EST Article-I.D.: egg-id.457 Posted: Thu Nov 19 17:08:39 1987 Date-Received: Sat, 21-Nov-87 17:51:02 EST References: <3387@adobe.COM> Organization: Idaho National Engineering Laboratory (INEL) Lines: 54 > An interesting variation on this is to represent bitmaps as hexadecimal. This > is, in fact, a 2-to-1 loss (not really a compression scheme), but it has > the property that there is an external "table lookup" mechanism implied by > the compression scheme. In particular, the ASCII character code system is > used to represent the hex digits, which are then interpreted as base 16 > numbers instead of characters. The "table lookup" is implicitly the > ASCII character set. > > I started thinking about using, say, the Macintosh Screen Fonts as a kind of > table for bitmaps. A bit pattern could be represented by a single byte if > it happened to match a screen font character in a system font (modulo the > problem that someone could edit the fonts). Depending on the font, this > could be quite a substantial compression scheme. But it suffers from being > "context-dependent" in the same sense that the previous examples were, since > it would rely on a Macintosh-specific resource. > > Glenn Reid > Adobe Systems This is exactly what I am currently tring. I have 512 by 512 by 8 bits per pixel images that I am hardcopying (monochrome). I had been using an imagen printer with its network interface. The technique I used was to map each source pixel to one of 17 4 by 4 bitmaps, each populated with from 0 to 16 `on' bits. This allows quantizing the image into 17 gray shades but still yields 75 hardcopy pixels per inch. (The imagen supports 300 dots per inch). This worked great with the high speed network interface. But the imagen has been replaced by an Apple Laserwriter connected on a Sun3 via a 9600 baud serial line. Converting the 8 bit source pixel to a 16 bit bitmap doubles the data. Now the Apple speaks postscript which needs the bitmaps encoded in ascii, another doubling. One megabyte at 9600 baud is too slow. Now for the kicker. Maybe someone can help me fix my bug. I don't know a thing about postscript. I have the manuals on order from Adobe, but procurement here is slow. I'm working blind. With the sun software came a little demo postscript program that created 2 `characters' in a font and printed them out various ways. I modified the program to create the 17 bitmaps I had and called them [0-9,a-g]. Now I should be able to map the image into the character set and `print' it with 7 bits (one character) per pixel with a little overhead for the `carriage return/linefeed'. Well this works until about two thirds the way through a 512 by 512 image. The printer then reports back a `VMerror'. Is this a virtual memory error? Is there some resource that I need to release (per line?)? Any pointers or comments would be appreciated. Sorry, I believe the source postscript is proprietary, so I can't post the code. -- Linn Hower lh1@INEL.GOV Phone: 208-526-9353 lh1%INEL.GOV@uiucuxc.ARPA