Xref: utzoo comp.lang.postscript:7862 comp.dcom.fax:174
Path: utzoo!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!math.fu-berlin.de!tmpmbx!netmbx!jrobie
From: jrobie@netmbx.UUCP (Jonathan Robie)
Newsgroups: comp.lang.postscript,comp.dcom.fax
Subject: Re: Compression of image matrices
Keywords: images, data compression,
Message-ID: <2072@netmbx.UUCP>
Date: 11 Mar 91 14:16:13 GMT
References: <11757@pasteur.Berkeley.EDU>
Organization: netmbx, Berlin, West Germany
Lines: 40

In article <11757@pasteur.Berkeley.EDU> gilge@ICSI.Berkeley.EDU (Michael Gilge) writes:
>We are often faced with the problem of transmitting large image matrices 
>to a postscript printer, e.g. sampled images or screen captures from X.
>This causes large transmission times and we are thinking about compressing
>the binary data before transmission. Together with the data, a postscript 
>decompression program is also send to the printer. The printer applies 

You can cut your data size in half without any compression by simply
transmitting the binary image data instead of converting it to ASCII
heas in the standard PostScript format.  This will also require fairly
minimal processing time.

However, are you *sure* that you processing is due to transmission times?
Remember that PostScript will scale the images to match the space allotted
to them.  If you do not carefully ensure that you are printing at same
size, a large image at high resolution can tie up a PostScript printer
for a long time.  You might want to monitor network activity or compare
times for images printed at same size.:d

>Before we start writing anything, has anybody ever done something like that?
>Especially is there a postscript program to decode fax Group3 encoded
>bitmaps?

What are you sampling with?  You will get very little compression for high
quality grey scale or color images using Group3.  In fact, Lempel-Ziv and
most of your other common compression mechanisms get less and less useful
as your grey scale information gets better.  Unfortunately, the more
appropriate methods for this kind of data are defined in the Frequency
Domain, and I suspect that the amount of calculation involved would
bog down your printer more than the savings in transmission time.

>
>Heinz W. Schmidt, hws@icsi.berkeley.edu
>Michael Gilge,    gilge@icsi.berkeley.edu
>
>International Computer Science Institute
>1947 Center Street, Suite 600
>Berkeley, California 94704
>Phone: 1-415-642-4274-134
>Fax:   1-415-643-7684