Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #746

Re: my response to some recent posts

Show all headers | View raw

jules Gilbert <jules.stocks@gmail.com> wrote:

(snip)
> Oh, one additional difference... I have a program.  It works too.
> Last week I showed it to a friend.  In C, on my laptop, he edited the
> source code, re-compiled it, and he ran it.  He made changes, he was
> driving.   About my friend, he's a better C programmer than I am.  I
> suppose I'm fair, but he's an expert, one of the best programmers I
> have ever worked with.  When I have something difficult to code I give
> it to him.  For when I want it done right.

Coding ability doesn't have much to do with the ability to write
good compressors. It does have to do with making one run fast enough
to be useful, though.

> So what was the program?, well it wasn't a compressor.  Something like
> that I suppose...

> Many times compressors are rated in terms of their ability to predict
> the next bit in a series of bits.  Prediction is useful because it's
> not necessary to send what can be predicted at the RCVE station.  (Why
> send it when you can predict it?)  And this model, this paragraph of
> discussion isn't about subsequent re-compression of RAD, this is all
> true for conventional compression.

Some time ago, I wrote a JBIG2 generic compressor from the JBIG2 spec.
(The decompressor is built into Adobe reader, so I didn't have to
write one of those. Also, I had a good way to test my implementation.)
JBIG2 is for compressing bilevel (black and white but no gray) images.

The prediction is based on neighboring, previously encoded pixels,
up to 16 of them. That is then used for an arithmetic coder, which
codes each bit based on its probability. It is significantly slower
than LZW, mostly because it goes bit by bit instead of byte by byte.

In any case, yes, if you can predict a bit and use that as the input
to an arithmetic coder, and if the prediction only depends on previously
seen bits (so the decoder can make the same prediction) then, yes,
you can build a compressor.

The problem, then, is improving your predictions. To do that, you need
to know some statistics of the data source. 

For lossless compression of scanned text images, JBIG2 does pretty well.
The context, values of the 16 predictor bits, predict reasonably well
to greatly reduce that file size.

-- glen

Back to comp.compression | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

my response to some recent posts jules Gilbert <jules.stocks@gmail.com> - 2012-01-09 06:50 -0800
  Re: my response to some recent posts Jim Leonard <mobygamer@gmail.com> - 2012-01-09 08:25 -0800
  Re: my response to some recent posts stan <smoore@exis.net> - 2012-01-09 14:03 -0500
  Re: my response to some recent posts Alex Mizrahi <alex.mizrahi@gmail.com> - 2012-01-09 21:54 +0200
  Re: my response to some recent posts glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-09 21:41 +0000
    Re: my response to some recent posts jules Gilbert <jules.stocks@gmail.com> - 2012-01-09 16:20 -0800
      Re: my response to some recent posts Jim Leonard <mobygamer@gmail.com> - 2012-01-09 20:24 -0800
  Re: my response to some recent posts Thomas Richter <thor@math.tu-berlin.de> - 2012-01-10 09:56 +0100
  Re: my response to some recent posts Sebastian <s.gesemann@gmail.com> - 2012-01-10 04:42 -0800
    Re: my response to some recent posts Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-10 21:08 -0800
      Re: my response to some recent posts jules Gilbert <jules.stocks@gmail.com> - 2012-01-11 17:48 -0800
        Re: my response to some recent posts Earl_Colby_Pottinger <earlcolby.pottinger@sympatico.ca> - 2012-01-12 05:04 -0800

csiph-web