CCITT encoding in PDF files – G31D CCITT data overview

In my second article on CCITT encoding I am going to explain exactly how 1D decoding works. Just to make life complicated, this can have several names. I will be referring to the Group 3 One-Dimensional as G31D. This has also been referred to as 1D CCITT in our office (why complicate things ey..?).

A PDF file data stream encoded in this mode is one of the easier CCITT data structures to decode. Firstly here are some keywords that would make it easier to understand how G31D works.

Pixel run- Usually 1-bit, 1 for Black and 0 for White. A block of pixels all the same.
Scan line– The width of data from one end of the page to the other.
Code Words– This contains information regarding what the data does eg makeup or Terminating.
Run Length– Block of either White or Black bits to be decoded/ encoded.
End of line(EOL)- Unique 12-bit code word used to determine the start and end of a scan line.
Return to control(RTC)- Six EOL code words occurring consecutively usually determines the end of the file. EOL & RTC would become more obvious in later blogs.

That is quite a lot of jargon so in my next article I will explain how it all works and how we read all this data.

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