Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!leech
From: leech@Apple.COM (Jonathan Patrick Leech)
Newsgroups: comp.lang.postscript
Subject: Re: compressed images
Message-ID: <33331@apple.Apple.COM>
Date: 20 Jul 89 18:33:53 GMT
References: <59760@philabs.Philips.Com> <1231@atanasoff.cs.iastate.edu>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 32
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <1231@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu.UUCP (John Hascall) writes:
>In article <59760> jcm@nori.Philips.Com (John Martin) writes:
<re run-length encoded images>
>>I realize that the file transmission time will be more than offset by
>>the decompression time, but am willing to trade off time for file
>>size.
>    I found that it was faster to send uncompressed data, than to
>send compressed data (at least at 19.2 Kbaud which is what we run).

    I have implemented run-length decoding of a binary stream
(Mac PackBits format, actually :-), rendering the entire image with
one operator as opposed to the multiple invocations of image in your
approach.  The images are much smaller, but decoding takes several
times longer than just dumping the raw bits (~4 minutes/full page
image encoded, ~1.5 minutes/full page in straight binary).  This is
over Appletalk, much faster than a 19.2K line, so you might show a net
increase in speed.  You probably couldn't use binary on a serial line,
though, so there goes half your bandwidth.

    I've been tweaking my decoding procedure for a while, but haven't
gotten the speed up enough to show net gain.  This is why I was asking
about faster PostScript controllers recently; however, it doesn't seem
that Hyperscript running on a Qume goes any faster than Adobe
PostScript on an NTX, in this particular (unusual) application.

    I can't post the code, so don't ask.  It isn't hard to write,
though - I started learning PostScript two months ago.
--
    Jon Leech (leech@apple.com)
    Apple Integrated Systems
    __@/