Hyper-Optimization of PDF Scans

Mind: BLOWN.

The other night Robert threw a bunch of PDFs my way, scans from a Xerox office copier that needed to be converted to JPEG. Child's play for ImageMagick, even with dozens of files to convert. So, off we go...

The only sticking point was figuring out what DPI to rasterize them at. The nominal resolution of the PDFs appeared to be impossibly low. With default settings, ImageMagick produced a near-screen-res image that lost a ton of detail, detail I could see in the PDF. Plus, the resulting JPEG file sizes were already larger than the (tiny) PDFs. Confusing, since you'd expect a PDF of a scan to contain nothing but a bitmap; the converted JPEG file should be within a few K of the same size. But at a resolution that visually matched the PDF's detail level (300dpi), the output file was almost 10x the size of the input! Something weird was going on.

I decided to pull one of the PDFs into Inkscape (think: open-source Adobe Illustrator), to see if I could at least find the native resolution of the embedded bitmap (the one I thought should be the only thing in the file). That's when things started to get weird.

Turned out, the file didn't contain a single embedded bitmap image object. It contained NINETEEN distinct component objects. The base image was that expected embedded bitmap, which was indeed stored at the near-screen-resolution nominal dimensions. Yet, as I'd proved to myself by zooming in on the PDF, there was far too much detail for that resolution!

The trick was in those other 18 objects. I don't know if this was Xerox's code, or the latest Adobe PDF creator optimizations, but whatever the source... the image had been deconstructed, and any areas that required extra detail — mostly, the white lettering printed against the dark background art — had been stored in masked layers placed on top of the low-res image. Those layers are all much higher resolution than the background, but each one contains only a single color so they're stored as one-bit masks, requiring a few kilobytes at most to store.

Keep in mind, this optimization was all done 100% automatically by the copier's scan-to-PDF function! So, upshot is that even though the file is tiny in size, it contains all the detail of a much higher-res image. And any conversion to JPEG or other fixed-resolution format would necessarily result in a much larger file than the PDF. I ended up pegging the rasterization at 150 dpi and output 85%-quality JPEGs, which tended to be roughly 2-3x the filesize of the source.

Craziness.

The first image here is one of the output files. The second I created in inkscape, showing the structure of the input PDF — each box is a non-background layer, green for white text and blue for detail sections in the background art, and the background image is dimmed so the detail elements stand out more clearly.

The scanned image

Structure of the scanned PDF

Detail

Structure detail

Community Participation, Done Right (Lawyers Too!)

The Fedora Project Contributors' Agreement (sometimes/formerly "CLA", the L is License/ing) must be signed by everyone who registers with the Fedora Account System and receives credentials allowing them to contribute to the project. (That includes software packaging, wiki editing, code checkins, and so on.) It sets the tone both for members' activities within the community, and for that community's relationship with its leaders.

For an open-source, community-driven project's organizational body to be respectful of that community, it mustn't put its own interests ahead of theirs. In fact, it shouldn't even have a concept of "its own interests" distinct from theirs; its only interests are the community's. Any goals that organization has should be narrowly defined, and any rights or authority it asserts should, when faced with conflict or overlap, be deferred. That's the model of a responsible governing body, one that wishes only to consolidate and guide the efforts of its contributors for the benefit of all involved, not appropriate those contributions for its own benefit or profit.

That's why, for Fedora contributors agreeing to & signing the CLA, almost more important than what that does mean is what the agreement doesn't mean. And why, in recognition of that fact, the text of the CLA opens with explicit statements of both points:

The Fedora Project Contributor Agreement

http://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement

Goal

We require that contributors to Fedora (as defined below) agree to this Fedora Project Contributor Agreement (FPCA) to ensure that contributions to Fedora have acceptable licensing terms.

Non-Goals

The FPCA is *not* a copyright assignment agreement.

The FPCA does *not* somehow supersede the existing licensing terms that apply to Fedora contributions. There are two important subpoints here. First, the FPCA does not apply to upstream code (or other material) that you didn't write; indeed, it would be preposterous for it to attempt to do so. Note the narrow way in which we have defined capital-c "Contribution". Second, the main provision of the FPCA specifies that a default license will apply to code that you wrote, but only to the extent that you have not bothered to put an explicit license on it. Therefore, the FPCA is *not* some sort of special permissive license granted to any party, despite the explicit choice of a more restrictive license by you or by upstream developers.

...Commendable. And why FESCo (the Fedora Engineering Steering Committee), the Fedora Project Board, and anyone else involved should be commended. In this time when free websites have Terms of Use claiming exclusive ownership of everything their users do on the site, this type of dedication to putting the community first — even in their lawyers' fine print — is all too rare.

Posted via email from ferdnyc's posterous