Xref: utzoo comp.unix.wizards:8348 comp.graphics:2442
Path: utzoo!mnetor!uunet!husc6!bbn!mit-eddie!bloom-beacon!gatech!ncar!noao!mcdsun!mcdchg!clyde!watmath!watcgl!awpaeth
From: awpaeth@watcgl.waterloo.edu (Alan W. Paeth)
Newsgroups: comp.unix.wizards,comp.graphics
Subject: Re: Any efficient ways of storing binary or image files ?
Message-ID: <4280@watcgl.waterloo.edu>
Date: 5 May 88 16:52:10 GMT
References: <2191@m2cM2C.ORG>
Reply-To: awpaeth@watcgl.waterloo.edu (Alan W. Paeth)
Organization: U. of Waterloo, Ontario
Lines: 79
Keywords: Image Storage

In article <2191@m2cM2C.ORG> chiang@m2c.ORG (Rit Chiang) writes:
>
>Does anyone know of a mechanism in storing binary or image files in
>a way similar to SCCS delta on text file (e.g. storing incremental
>changes only) ?  The goal is to store these non-ASC files
>in a disk space efficient way.

If the image data is 8-bit grey or 24-bit color (intensity channels are sitting
in bytes), then UNIX "compress" would work, except that those feature details
which are spatially adjacent in the 2D image (and show strong coherence), are
widely separated (by a scanline's worth of data) when represented as a 1D data
stream.

APPROACH

A useful fix is to preprocess the image so that every pixel has been subtracted
into the pixel immediately above it. The modified image can now be compressed
into a more compact file for shipping. A set of 2D raster op tools can do the
coding easily -- take two copies of the input, displace the first by one pixel
in y, and subtract. The subsequent compression gives (in my experience) roughly
a 50% savings over straight "compress" and the file is may be reconstructed
exactly.

On reception, the file is uncompressed and then the inverse transform applied:
each input pixel is subtracted into the pixel located immediately above in
the *output* of the previous row. This can *not* be done using said stock tools,
because the decoder is forming the next pixel as a function of both the input
and output streams. It is better to write the whole thing as one tool (which
I've done), and as the function is nearly symmetrical, the code has one simple
"decode mode" switch. The program must also begin in all cases by copying the
first line of input to the output verbatim, as no difference can be formed.
Also, note that whereas decode(code(x)) = x, code(decode(x) != x.

CODE

For input and output data arrays I(r,c) and O(r,c) with 0<=r