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…
This post is part of our “Understanding the PDF File Format” series. In each article, we discuss a PDF feature, bug, gotcha or tip. If you wish to learn more about PDF, we have 13 years worth of PDF knowledge and tips, so click here to visit our series index!
Latest posts by Mark Stephens (see all)
- My experience of a Turkish bath (visiting Istanbul for DevFest) - November 24, 2017
- My 5 key takeaways from JavaOne 2017 - October 6, 2017
- My notes and pictures from thursday JavaOne 2017 - October 5, 2017
- My notes and pictures from Wednesday JavaOne 2017 - October 5, 2017
- My notes and pictures from Tuesday JavaOne 2017 - October 4, 2017