Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!mcnc!uvaarpa!virginia!uvacs!rwl
From: rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky)
Newsgroups: comp.lang.postscript
Subject: Run-length encoding for image data?
Message-ID: <2387@uvacs.CS.VIRGINIA.EDU>
Date: 6 May 88 13:51:12 GMT
Organization: U.Va. CS Department, Charlottesville, VA
Lines: 47

Has anyone successfully implemented a run-length-encoding scheme for
compressing pixel information sent to the image operator?  Several attempts
I have made actually *increased* the processing time of large images on the
Apple LaserWriter.  I'd love to here about a method for speeding up the
throughput of images.  If you're interested in what I've tried, read on...

				*******

PostScript is quite convenient for displaying pixel images, but if the
printer hangs off a serial line, it's a real bitch waiting for something
significant like a Sun screendump to be printed.  Most of the time (about
6 minutes) is spent in downloading all those hex numbers to the image operator
at 9600 baud (portrait mode, that is... landscape takes another 25 minutes for
rotation).

Initially, I tried to write a run-length-encoding protocol to speed up the
transmission by sending eight pixels per character rather than the four pixels
per character you can get via readhexstring.  I quickly ran into the snag that
things like ^S, ^T, etc have to be guarded, so I set aside one character to
be an "escape" so that the few bit patterns which corresponded to ^S, ^T, etc
could be passed in two bytes.

Unfortunately, I had to specially process the input to translate the two-byte
symbols back into the original characters.  Whether I used read to grab a
character at a time or readstring to grab a whole string to operate on, the
times were ultimately worse than 6 minutes even though I was sending half the
number of bytes down the pipe.

MILD BUT WARMING FLAME:

If the usual processor for PostScript engines (I suppose my LaserWriter's
68000 is the usual) can't handle all those manipulations, I think that Adobe
should include a compressed-data read operator in a future release of
PostScript.  As far as I can tell, it can't be implemented in the interpreter
with any efficiency to make it worth while.  I can't believe a text/graphics
page description language worth its salt could not afford to make a concession
to the reality of the systems in which it is used.

Well, that's one to think about Adobe...  If anyone has any suggestions (short
of getting faster printer or a parallel interface) I'd appreciate hearing about
them.

-- 
| Ray Lubinsky,                    UUCP:      ...!uunet!virginia!uvacs!rwl    |
| Department of                    BITNET:    rwl8y@virginia                  |
| Computer Science,                CSNET:     rwl@cs.virginia.edu  -OR-       |
| University of Virginia                      rwl%uvacs@uvaarpa.virginia.edu  |