Written notes
Three pieces of writing that take longer than a control label allows.
The panel is terse by design. It reports a pixel count, a physical measurement and a density, and it names which quantity is being held while you edit another. What it cannot do, in the width of a rail, is argue — and nearly every difficult case that arrives here is an argument rather than a calculation. A vendor asks for a figure. A portal refuses a file without saying which of its two conditions failed. Somebody is sure a photograph got sharper when a header field changed.
So these exist. Each one starts from a question that is asked in the same words every week, works it through in figures rather than adjectives, and finishes somewhere you can act on. None of them is a tour of the interface; the interface is four controls and does not need one. Where a piece reaches the edge of what this instrument should do, it says so plainly rather than selling you the next feature.
DPI is metadata, not detail
Settles what the resolution field in a file is a claim about, why editing it leaves the picture bit-for-bit identical, and how to tell which of the two size operations a given instruction is asking for.
reading time about 4 minutes
Why upscaling loses detail
Works through what a kernel does between two known samples, why no entry in the list recovers information the sensor never wrote down, and where a reconstruction tool becomes the correct instrument instead.
reading time about 4 minutes
Preparing a scan to a specified resolution
Takes a requirement stated as a density and a paper size, turns it into a pixel count before the scanner is touched, and lists the two failures that survive a correctly written header.
reading time about 5 minutes
The one identity all three come back to
Every piece below is ultimately an expansion of a single line of arithmetic, and it is worth having in front of you before you start reading. A pixel count equals a physical measurement multiplied by a density. Three quantities, one equation: fix any two and the third is determined, which is why no instruction involving only one of them is ever complete.
| Header says | Placed width | Placed height | Pixels changed |
|---|---|---|---|
| 600 dpi | 10.50 cm | 14.85 cm | none |
| 300 dpi | 21.00 cm | 29.70 cm | none |
| 150 dpi | 41.99 cm | 59.40 cm | none |
Read the table as a warning rather than a reference. The same file is the same file in all three rows; only the number in its header differs, and with it the size a printer will place it at. Nothing in those rows required the picture to be touched.
What is not written up here yet
There is no piece on choosing between the kernels, because the honest version is short enough to sit next to the control and is already there: going down, a windowed sinc gives the crispest result and rings on hard edges; going up, bicubic is smoother and rings less; bilinear is neither and exists for speed. There is no piece on file size either, because this tool does not target one, and writing a guide to an operation the site refuses to perform would be advertising dressed as help.
The gap that does bother us is colour. An export produced in resample mode goes through the browser’s encoder and loses the embedded profile, which matters to anybody submitting work to a press, and the note below the export control says so in one sentence where it deserves several hundred words. It is the next thing to be written.
Back to the panel
Four routes take a file. They differ in what they expect you to be holding when you arrive rather than in what they can do once the image is open.