RetouchPi JPEG to PDF: One Page, One Pixel per Point

PDF is a very large format, and "put one picture on one page" needs only a small corner of it: a catalog, a page tree of one, one image object, one content stream that paints it, and a cross-reference table. This export writes exactly those five and nothing more - fonts, annotations and forms are parts nobody asked for, and a writer that pretends to understand them emits files other readers reject.

• One page, not a stack. /Type /Page occurs once in the file; there is no multi-page merge on this road - imposition happens elsewhere, first.
• Page size equals document pixels. /MediaBox [0 0 1500 1500]: one pixel per point, which is the 72 dpi reading. Fifteen hundred points is about 20.8 inches or 52.9 cm - the size on screen is the size on paper.
• The colour is one JPEG. /Filter /DCTDecode with /ColorSpace /DeviceRGB, stream length 48,603 bytes; the PDF layer does not re-compress it - whatever bytes the canvas encoded are the bytes wrapped.
• Metadata stays spare. /Producer (RetouchPi), /Title (subject-2) taken from the document name, and startxref present; nothing else dressed up.

The sample is a real studio shot (white background, reflection included), not colour blocks drawn for a demo - and the gap between the 48,033-byte source JPEG and the 48,603-byte JPEG inside the export is exactly the one re-encoding discussed below.

The table below was run on one machine in one bundled Chromium on 2026-10-10, once per interface language; the timings are probe timestamps taken around each action and the sizes are the real byte counts on disk. The byte counts are identical in both languages - the export does not care which interface you clicked in.

Take the export apart: the colour stream is 48,603 bytes and the whole file is 49,388, a difference of 785 bytes - the catalog, the page tree, the 32-byte content stream and the cross-reference table all together. In other words this PDF is very nearly the JPEG itself inside a thin envelope.

• The colour is not the source JPEG's own bytes, though. The export runs the canvas JPEG encoder at quality 0.92; the source is 48,033 bytes and the stream's JPEG is 48,603. So this road is lossy - the loss is in that one canvas encoding, and the PDF layer adds no second compression.
• For lossless, do not take the PDF road. The layered and lossless exits are PSD and TIFF; the PDF's role in this family is to be sent out and looked at, or printed, not to serve as an archival master.
• The content stream is 32 bytes. It says one thing: paint that JPEG across the page. No other drawing instructions, hence nothing else that can go wrong.

A JPEG cannot hold transparency; PDF's answer is a second, one-channel image that the page multiplies the colour by - which is what a PNG's alpha is, said in PDF's own words. So the export of a cut-out document carries one object more: the colour /DCTDecode at 57,322 bytes plus an /SMask (/FlateDecode, /DeviceGray, 1500 x 1500) of 11,354 bytes, 69,668 bytes in all.

• An uncut document carries no mask. The opaque export reads back with /SMask absent - present when it should be, absent when it should not, which is exactly what a read-back can check.
• The cutout leaves the source layer alone. The one-click cutout lands as a layer mask with every source pixel untouched; the mask can still be inverted, feathered or painted by hand before you export.
• Under the subject is not white but see-through. In a reader the checkerboard becomes whatever lies beneath - a slide, a web page, the printer's paper white; want a white ground, do not cut.

The document carries no resolution field, so the export writes the page size at one pixel per point - the 72 dpi reading: 1500 pixels on screen become 1500 points on paper, about 20.8 inches or 52.9 cm wide. That is the right reading for sending something out to be looked at; printing at a named size and dpi is arithmetic you do yourself.

• A4 at 300 dpi wants 2480 x 3508 pixels. To fill an A4 sheet without interpolation the document must be that many pixels; the export will not resample for you.
• Five by seven inches at 300 dpi wants 1500 x 2100 pixels. The sample's 1500-wide happens to cover the five-inch side - a coincidence of arithmetic, not a preset the export offers.
• No paper presets and no dpi field. The page size follows the document's pixels and nothing else; want another size, change the document's pixel dimensions first, then export.

Half the value of a capability page is in the word "not". This page does not claim:

• No reading PDF in. The file dialog's allow list has no .pdf; hand the exported file back and the tab does not move, the notice reading "That file could not be decoded as an image." This page turns JPEG into PDF; it is not a PDF editor.
• No multi-page merging. The read-back counts /Type /Page at 1; one document gives one page, with no imposition and no appended pages.
• No prepress colour. The colour stream is /DeviceRGB; there is no CMYK working mode and none of the prepress proofing machinery. Whether CMYK files open is another page's business; this page's exit is sRGB.
• No lossless claim. The colour is a JPEG encoded by the canvas at quality 0.92; lossless lives on the PSD and TIFF roads.
• No offline claim, and no promise that files never leave the machine. Opening, editing and export stay on this machine; AI generation and AI edits are the one step that reaches a server, priced in credits and quoted before you commit.