Support JBIG gray level images via multiple planes

My JBIG module source code for inspiration.

It is my understanding that there was an attempt in the standards organizations to use JBIG for more than bi-level images, but the effort failed. Are you aware of any implementations besides your own?

Is the compression level very good as compared with modern compression algorithms?

JBIG1 has been replaced by JBIG2.

It is written in JBIG library documentation. I have followed documentation only.

If you want to encode a grey-scale image, you can use the library
function

void jbg_split_planes(unsigned long x, unsigned long y, int has_planes,
int encode_planes,
const unsigned char src, unsigned char *dest,
int use_graycode);

It separates an image in which each pixel is represented by one or
more bytes into separate bit planes. The dest array of pointers to
these bit planes can then be handed over to jbg_enc_init(). The
variables x and y specify the width and height of the image in pixels,
and has_planes specifies how many bits per pixel are used. As each
pixel is represented by an integral number of consecutive bytes, of
which each contains up to eight bits, the total length of the input
image array src[] will therefore be x * y * ((has_planes + 7) / 8)
bytes. The pixels are stored as usually in English reading order, and
for each pixel the integer value is stored with the most significant
byte coming first (Bigendian). This is exactly the format used in raw
PGM files. In encode_planes, the number of bit planes that shall be
extracted can be specified. This allows for instance to extract only
the most significant 8 bits of a 12-bit image, where each pixel is
represented by two bytes, by specifying has_planes = 12 and
encode_planes = 8. If use_graycode is zero, then the binary code of
the pixel integer values will be used instead of the Gray code. Plane
0 contains always the most significant bit.

The value planes is a standard part of JBIG file structure. This value could contain anything else than 1. It is not my invention.

Compression seems to be signifficantly better. JBIG2 seems to be implemented in TIFF only.

gconvert.exe lena.pcx lena.jbg
gm convert -compress JBIG2 lena.pcx lena.tiff

04.01.2026 00:38 184620 lena.jbg
03.01.2026 19:17 254218 lena.pcx
04.01.2026 00:39 263955 lena.tiff

There is no support for JBIG2 in the Windows build, or in libtiff either. If JBIG2 is accepted, it is being mapped to uncompressed. Compare with an ordinary JPEG or JP2 file instead.

This is not fair, JPEG is lossy format. JP2 is also lossy. Compression ratio is not comparable.

The only effective lossless format is PNG
04.01.2026 02:02 161 704 lena.png
and PNG performs better, but this is not a compression competition. Gray level JBIG could occur in wild. Standard demo program pbmtojbg is capable to create gray JBIG.

JP2 supports lossless. Unfortunately, it was not working in GM due to a tiny bug (fixed in Mercurial).

gm convert lena.pcx -define jp2:rate=1.0 lena.jp2

WEBP supports lossless.

gm convert lena.pcx -define webp:lossless=TRUE lena.webp

JXL is supposed to support lossless, but for some reason requesting it is throwing an error in my build.

Here are some sizes I obtain in various lossless formats. My Lena image is 256x256 whereas yours is 512x512:

From the above, I see that lossless JP2 is the smallest. Can you beat it?

I has been explicitly written that I am not doing compression competition - it is only interesting. I originally want to support missing JBG variant, as it has been originally documented and implemented. JBG apparently does not achieve the best compression.

Anyway, you have made test on a different image that I do not have. I have attached my image to this thread.

JBG documentation claims to achieve better compression ratio on Grey code (not gray). But there is no information in a file whether Grey code or standard encoding used.

If I convert your lena.pcx to lossless JP2 it requires 159,285 bytes. Your JBIG file required 184,620 bytes.

Ticket moved from /p/graphicsmagick/bugs/762/

Can't be converted:

• _milestone: v1.0_(example)

Changed this to a feature request given that multi-level JBIG does not appear to be in actual use (although documented) and it is less efficient than more modern algorithms for lossless compression.