CCITT encoding in PDF files – black and white facts

CCITT encodes black and white data. It does this by encoding runs of black or white pixels. This data can be stored using one bit (0 or 1), so which do we use for black?

As most images contain more white than black, we assume that we start with white. For cases where we do not start with white, we add a marker at the start to show this. If we encode black as value 1, we just set these bits in our decompressed data – we do not explicitly need to set white values (because it is binary, not setting a value to black means that it is white).

But sometimes, we find that there are more pixels that are black that white. Well, in this case, we can just invert the image (flipping bits is very fast) and then we get the best compression. All we need is a flag (BlackIs1 in the PDF file format – it’s default value is false) so flag that the image data needs inversion to appear correctly.

Most PDF libraries, take care of this automatically for you but if you are directly the accessing the CCITT data, you will need to be aware of the possibility the image data may need to be inverted.

So there you have it – in black and white…

Do you need to read or write Tiff files in Java?

Our JDeli image library offers a range of advantages over ImageIO and alternatives for Tiff files, including:

• prevents heap related JVM crashes
• reads 1-32 bit bilevel, grayscale, rgb, argb, cmyk, acmyk, ycbcr Colorspaces, and converts to sRGB BufferedImage
• implements both Little and Big Endian Byte Ordering
• decompresses uncompressed, CCITT group 3 and 4, Deflate/Adobe Deflate, LZW, Packbits
• support for Single, Multi-file, Tiling, Planar (Chunky, Separated), Predictor, 16,32 bit floating samples
• improve read performance
• supports threading
• superior image scaling algorithms

Are you a Developer working with PDF files?

Our developers guide contains a large number of technical posts to help you understand the PDF file Format.

Do you need to solve any of these problems?