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