Aquileo | Recent changes to 76: Support JBIG gray level images via multiple planes

Aquileo | #76 Support JBIG gray level images via multiple planes

Tue, 06 Jan 2026 14:29:24 -0000

summary: Support of JBIG gray level images --> Support JBIG gray level images via multiple planes

Aquileo | #76 Support of JBIG gray level images

Tue, 06 Jan 2026 14:28:38 -0000

summary: Wrong support of JBIG gray level images --> Support of JBIG gray level images

Aquileo | #76 Wrong support of JBIG gray level images

Tue, 06 Jan 2026 14:26:05 -0000

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

Can't be converted:

_milestone: v1.0_(example)

Aquileo | #762 Wrong support of JBIG gray level images

Sun, 04 Jan 2026 22:28:55 -0000

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

Aquileo | #762 Wrong support of JBIG gray level images

Sun, 04 Jan 2026 21:12:15 -0000

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.

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.

Aquileo | #762 Wrong support of JBIG gray level images

Sun, 04 Jan 2026 16:07:26 -0000

Aquileo | #762 Wrong support of JBIG gray level images

Sun, 04 Jan 2026 01:03:26 -0000

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.

Aquileo | #762 Wrong support of JBIG gray level images

Sun, 04 Jan 2026 00:30:46 -0000

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.

Aquileo | #762 Wrong support of JBIG gray level images

Sat, 03 Jan 2026 23:42:15 -0000

Compression seems to be signifficantly better.

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

Aquileo | #762 Wrong support of JBIG gray level images

Sat, 03 Jan 2026 23:16:23 -0000

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.