Xref: utzoo comp.lang.postscript:7831 comp.dcom.fax:167
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mcnc!duke!george.mc.duke.edu!klg
From: klg@george.mc.duke.edu (Kim Greer -- rjj)
Newsgroups: comp.lang.postscript,comp.dcom.fax
Subject: Re: Compression of image matrices
Keywords: images, data compression,
Message-ID: <22055@duke.cs.duke.edu>
Date: 8 Mar 91 19:44:32 GMT
References: <11757@pasteur.Berkeley.EDU>
Sender: news@duke.cs.duke.edu
Followup-To: comp.lang.postscript
Organization: Duke University Medical Center, Durham, NC
Lines: 45
Nntp-Posting-Host: george.mc.duke.edu

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
+ .....
+Before we start writing anything, has anybody ever done something like that?
+Especially is there a postscript program to decode fax Group3 encoded
+bitmaps?
+
+Any hints are greatly appreciated.
+
+Heinz W. Schmidt, hws@icsi.berkeley.edu
+Michael Gilge,    gilge@icsi.berkeley.edu

  I wrote a (series of) program(s) sometime back to get around a similar
problem on a non-PostSript printer (HP LJII) and later for a PostScript
printer.  The big problem with the HP was that I often over-filled the
memory, resulting in either garbage or blanks.  What I did was to take the
image matrix and search by rows and/or columns to see how big of a
rectangle, rather than a single pixel, that could be sent.  If the entire
row was the same value for all pixels, then a significant speedup could be
achieved.  Better still was a row that was identical to the previous row.
Even better was rows of "blank" or non-printing values, in which nothing had
to be written at all (but be sure to increment the next starting position to
the correct location).  You of course win big with nearly-uniform images and
images with lots of big, non-printing (blank) spots.  While this causes
variable computer->printer dump times, no one is likely to complain.

  If you do the "compression" after re-"digitizing" the image to, say, 16
gray levels, then you might gain, by having less "values" to have to look at
and sort, rather than the original, you might gain again.  I'll have to
think about that a little more.

  Anyway, if you are fairly comfortable with writing PostScript, I hope the
above info will gain you a little, at least.  I personally would try to stay
away from "compressing" in the sense of the PD unix "compress" program
style, though someone else may have may better ideas on the subject than I.

Good luck.

-- 
Kim L. Greer                       
Duke University Medical Center		 klg@orion.mc.duke.edu
Div. Nuclear Medicine  POB 3949		 voice: 919-681-5894
Durham, NC 27710  		         fax: 919-681-5636