_{Built for Miruiq — AI-powered data extraction from PDFs and documents.}

fastpdf2png

Ultra-fast PDF to PNG converter. Pre-forked worker pool, SIMD-optimized encoding, automatic grayscale detection, zero-copy RGBA rendering. MIT licensed.

Install

pip install fastpdf2png

Or build from source:

git clone https://github.com/nataell95/fastpdf2png.git && cd fastpdf2png
bash scripts/build.sh

Usage

CLI

# Single PDF
./build/fastpdf2png input.pdf page_%03d.png 150 8 -c 2

# Batch / streaming pool (many PDFs, max throughput)
for f in docs/*.pdf; do echo "$f\toutput/${f%.pdf}_%03d.png"; done | \
  ./build/fastpdf2png --pool 150 8 -c 2

Python

import fastpdf2png

images = fastpdf2png.to_images("doc.pdf")        # list of PIL images
fastpdf2png.to_files("doc.pdf", "output/")        # save PNGs to disk
data   = fastpdf2png.to_bytes("doc.pdf")          # raw PNG bytes
n      = fastpdf2png.page_count("doc.pdf")        # page count

# High-throughput batch processing
with fastpdf2png.Engine(workers=8) as pdf:
    pdf.to_files_many(pdf_list, "output/", dpi=150)

Node.js

const pdf = require("fastpdf2png");

pdf.toFiles("doc.pdf", "output/", { dpi: 150 });
const buffers = pdf.toBuffers("doc.pdf");
const count = pdf.pageCount("doc.pdf");

// Batch processing
const engine = new pdf.Engine();
await engine.toFiles("doc.pdf", "output/");
engine.close();

Performance

Single PDF worker scaling (150 DPI, compression level 2, Apple M-series):

Single-process throughput vs other tools (71-page mixed PDF, Apple M3 Max):

Smaller output files for grayscale pages thanks to automatic grayscale detection.

Batch processing (200 PDFs, 324 pages, --pool mode):

How it works

Rendering

Google's PDFium (the engine inside Chromium) renders each page into a raw RGBA bitmap using FPDF_REVERSE_BYTE_ORDER. This produces RGBA pixels directly — no BGRA-to-RGBA swizzle needed, and fpng can encode them with zero conversion overhead.

Grayscale detection

Before encoding, a SIMD-accelerated pass scans every pixel to check if R == G == B. Most document pages (text, tables, charts) are grayscale — detecting this lets us encode them as 8-bit PNG instead of 24-bit RGB, cutting data size by 66% with zero quality loss. On ARM this uses NEON vld4/vceq intrinsics; on x86 it uses SSE/AVX2.

PNG encoding

Instead of the standard zlib/libpng pipeline, we use libdeflate for compression and fpng for fast encoding. The compressed data goes directly into a pre-allocated output buffer — the PNG header, IDAT chunk, and IEND trailer are assembled around it with zero intermediate copies. CRC32 checksums use hardware-accelerated instructions (CRC32 on ARM, PCLMUL on x86). Each page is written with a single write() syscall.

Pool mode

The --pool command pre-forks N worker processes at startup. Workers stay alive and wait for jobs on pipes (zero CPU waste when idle). The parent reads PDF paths from stdin and dispatches them immediately to workers via pipe IPC. Large multi-page PDFs are automatically split into page ranges across workers for load balancing. Each worker loads PDFs into memory with read() and parses them with FPDF_LoadMemDocument64, eliminating syscalls during PDF parsing.

On Windows, pool mode uses CreateProcess with anonymous pipes — same architecture, Win32 APIs.

Memory pools

Each worker maintains process-local memory pools for pixel buffers and compression scratch space. After the first page warms up the pools, subsequent pages require zero malloc/free calls in the hot path.

CLI reference

fastpdf2png <input.pdf> <output_%03d.png> [dpi] [workers] [-c level]
fastpdf2png --pool [dpi] [workers] [-c level]    < job_list
fastpdf2png --info <input.pdf>
fastpdf2png --daemon

Pool mode reads pdf_path\toutput_pattern lines from stdin, one per line.

Platforms

License

MIT. See LICENSE and THIRD_PARTY_LICENSES.md.