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


Groups > comp.compression > #784

Re: JBIG2

From Thomas Richter <thor@math.tu-berlin.de>
Newsgroups comp.compression
Subject Re: JBIG2
Date 2012-01-18 21:59 +0100
Organization InterNetNews at News.BelWue.DE (Stuttgart, Germany)
Message-ID <jf7brd$87b$1@news.belwue.de> (permalink)
References <jf51vh$g76$1@speranza.aioe.org> <a59e68ad-b81a-4260-ba36-7fbfef6f9e94@n7g2000pbd.googlegroups.com>

Show all headers | View raw


On 18.01.2012 20:55, James Dow Allen wrote:
> On Jan 18, 6:58 am, glen herrmannsfeldt<g...@ugcs.caltech.edu>  wrote:
>> It seems that JBIG2 isn't a popular topic here, if anywhere.
>
> I read about JBIG two decades ago.  Was that similar to JBIG2,
> just somewhat simpler?

JBIG coding can be considered a subset of JBIG2, actually. JBIG2 allows 
also efficient coding of texture (shading) by special modes, and IIRC 
JBIG2 also allows you to build up an alphabet of glyphs (like a font) 
and compress only the errors relative to such a recognized set of 
glyphs. Of course, how to find such glyphs is left open - it is part of 
the implementation.

One minor point on which my recollection
> differs:
>
> Gray-scale images, e.g. 4 or 8 bits per pixel, *were* allowed, with
> successive planes encoded.

I believe we released an improved color version like about five years 
ago, but I was only indirectly involved in it.

> A *VERY* simple trick was used to get
> a win:
>     Instead of encoding
>       [ b0, b1, b2, b3 ]
> where b0 os MSB and b3 LSB, they encode
>       [ b0, b0 .xor. b1, b1 .xor b2, b2 .xor. b3 ]
> where the k'th developed bit (k>  0) has about the entropy of b{k-1}.

This is also known as Grey-code. It's actually a very old trick which 
was originally used in mechanical dials where a simple linear increment 
requires only one bit to change at each time, avoiding synchronization 
problems. This trick is also found in JPEG 2000 "MQ coder bypass coding".

> What kind of predictor do they use?  If it's linear, the win
> by switching to non-linear filter would be bigger
> than optimizing pixel selection.

It is not linear nor non-linear - rather context driven by a set of 
pixels in the causal neighbourhood of the pixel to code. As the pixels 
are binary (thus J-BI-G), the number of contexts remains limited (two 
per pixel - thus 1024 for ten pixels.) IIRC, it was basically a variant 
of the Q-coder that is used here, probably QM for JBIG and MQ for JBIG2, 
but I don't remember exactly.

Greetings,
	Thomas

Back to comp.compression | Previous | NextPrevious 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