FL PDF To Images

FL_PDFToImages does one thing: it renders every page of a PDF into an image, using PyMuPDF (the fitz library) under the hood, and hands you back a single batched IMAGE output with all the pages in it. It's the direct inverse of FL_ImagesToPDF, the same pack's node for going the other way - building a PDF out of images instead of extracting images from one.

The use case is straightforward. You've got a PDF - a scanned document, a reference sheet, an exported layout, a page you pulled off the web - and you want its content as image tensors so you can feed it into the rest of a ComfyUI graph: crop it, run it through a vision model, composite it, whatever comes next. This node is that first conversion step.

Two inputs, and the second one is the whole tuning knob. pdf is your input (the node's schema also allows a list of PDFs, so batch conversion of several documents in one call is supported). dpi (72–600, default 200) controls render resolution - literally dots per inch, the same concept as a print or scan setting. Higher dpi means more pixels per page, which means bigger, sharper output images, but also more memory and slower rendering. 200 is a sane default for on-screen review and general downstream processing; if you specifically need print-quality detail, or you're planning to zoom or crop tightly into a page afterward, push it toward 300–600 - but expect the size and time cost to scale with it.

One IMAGE output - all rendered pages, concatenated into a single batch.

Installing it. Standard Fill-Nodes routine - search "Fill-Nodes" in ComfyUI Manager, or clone it directly:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

• then restart ComfyUI. This one's a genuinely heavier install than most of the pack's utility nodes: PyMuPDF bundles its own PDF rendering engine (MuPDF), so it's a real compiled dependency rather than pure Python, not just a thin wrapper around something already in your environment.

Where people get burned. The most common issue is simply not thinking about dpi before running it on a large multi-page document - a high dpi on a 50-page PDF produces a genuinely large batch of genuinely large images, and if you hit a memory error, the fix is almost always to drop dpi rather than assume something's broken. The second thing worth knowing: because every page ends up concatenated into one batch, a PDF with inconsistent page sizes - mixed portrait and landscape, or pages of different physical dimensions - is working against the assumption that a batch tensor holds uniformly-sized images. If your source PDF isn't consistently sized page to page, expect the node to normalize dimensions somehow (padding or resizing) rather than producing a clean 1:1 batch, so a mixed-size document is a case worth sanity-checking the output on before you build a bigger pipeline around it.