Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compression > #784
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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