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

Groups > comp.compression > #780

Re: JBIG2

Show all headers | View raw

Thomas Richter <thor@math.tu-berlin.de> wrote:
> Am 18.01.2012 00:58, schrieb glen herrmannsfeldt:
>> It seems that JBIG2 isn't a popular topic here, if anywhere.

>> I am working with a JBIG2 encoder, processing scanned (mostly) text
>> pages, and wondering about the positions of the AT pixels.

(snip)
>> I wonder if anyone else has studied the optimal positions for
>> the AT pixels for different types of input files.

> Not myself, but certainly in our JBIG sub-committee. One of the reasons 
> why JBIG2 left the positioning of the free pixels open is that you can 
> tweak the last bit of performance out of the positioning of these 
> pixels, and that the algorithms that did this type of smart positioning 
> were, to my knowledge, patented and thus could not be included.

I hadn't thought about that. I did wonder if the decoders have a fast
path for the nominal positions, such that they would run faster.
(Specifically Adobe reader, as I am writing PDFs with them.)

> My best guess as how to position these pixels would be to observe the 
> entropy of the probability distribution conditioned on these pixels, and 
> pick the pixel that ensures the lowest entropy. This could certainly be 
> extended to an adaptive algorithm, or if feasible, a multi-pass 
> algorithm. There are probably heuristics, too, as where to place the 
> pixels, but they are unknown to me (not being much of a JBIG guy).

So far, I have tried a few different positions, sort of trial and error
convergence. 

Well, from the beginning my program would write out some statistics
at the end, including how many contexts were used, and I was surprised
how small it was.  Maybe a few thousand out of 65536. I had thought
that using more contexts would allow for better prediction, and
so better compression. My tests should that I sometimes get a little
better, and sometimes a little worse, maybe a few percent either way.

> Anyhow, the topic of JBIG is not off-topic at all here, and I'm glad 
> someone came with a more elaborate question [rather than the usual 
> nonsense we unfortunately see here so often.]

It is already pretty slow, so I don't think I want a fully adaptive
algorithm. If I found some positions that did better consistently I
would use those. 

I thought I would ask here before trying something more, in case it
had been done before. Still, I am surprised by how rarely I hear
about JBIG2 being used.

-- glen

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

Thread

JBIG2 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-17 23:58 +0000
  Re: JBIG2 Thomas Richter <thor@math.tu-berlin.de> - 2012-01-18 09:04 +0100
    Re: JBIG2 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-18 12:53 +0000
  Re: JBIG2 James Dow Allen <jdallen2000@yahoo.com> - 2012-01-18 11:55 -0800
    Re: JBIG2 Sebastian <s.gesemann@gmail.com> - 2012-01-18 12:17 -0800
    Re: JBIG2 Thomas Richter <thor@math.tu-berlin.de> - 2012-01-18 21:59 +0100
      Re: JBIG2 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-18 22:22 +0000
    Re: JBIG2 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-01-18 22:06 +0000

csiph-web