Rotate a folder of pictures by their tags

Reading first, deciding second

A folder of scans and a camera-roll dump share a shape: nearly every file carries the same defect, and a few of them do not. The expensive way to handle that is to decode everything and re-encode everything, which spends a generation of quality on the files that were already fine. This page reads the orientation field of every file first — a few hundred bytes from the front of each — and only then decides which ones to open.

The table above is the deliverable as much as the archive is. It lists every file, the value the queue read it as, and what was done about it, so that a queue of forty is auditable rather than a black box that returns a ZIP. A file carrying no orientation field at all is read as upright and shown that way, which is the same instruction and the same outcome, though not the same file. When the run finishes, the summary line underneath reads like the account a person would give: how many were already upright, how many were corrected and from what, and how many could not be processed and were passed through.

What the queue refuses to do

• It never guesses at a file with no tag, and never rotates by inference from the shape of the frame. Such a file is read as upright and copied through, exactly as a file whose tag says 1 is.
• It never re-encodes a file that did not need changing, so an already-correct JPEG in the archive is the identical file you dropped in.
• It does not silently downscale. A picture past the megapixel ceiling of this browser is returned untouched with the reason in its row, rather than quietly coming back smaller than it went in.
• It does not apply a fixed angle across the queue. That is a different feature with different failure modes and it is not built.

Questions about correcting a queue

Are the files that were already upright re-encoded too?

No, and that is the point of reading the tags first. A file whose orientation field already reads 1 needs nothing done to it, so it is copied into the archive byte for byte and never touches an encoder. On a typical camera-roll dump that is most of the queue, and re-encoding all of it to change nothing would spend a generation of quality on every one.

What happens to a file with no orientation tag?

It comes back exactly as it went in — copied into the archive byte for byte, never decoded and never touched by an encoder. What the table cannot do is tell you that is what you had: the reading pass takes an absent field and a field that reads 1 as the same instruction, upright, and the row says upright for both. Only the orientation page separates the two cases, because only there is the metadata block read in full. The outcome is identical either way, because a portrait photograph and a photograph lying on its side are indistinguishable to anything short of understanding what is in the frame, and this tool does not understand what is in the frame. Guessing would silently turn a perfectly good vertical picture on its side, which is a worse failure than doing nothing.

How many files can it take?

Files are decoded one at a time rather than all at once, so the queue length is limited by patience rather than by memory — but the finished archive is assembled in this tab before it is handed to the browser, so a few hundred large photographs will eventually exhaust the tab. If the assembly step reports that it ran out of room, run the queue in two halves and you will get two archives.

Can I turn every file by a fixed angle instead of by its tag?

Not in this version. Batch by fixed angle and batch straightening with a review grid are real features with real edge cases, and half of either would be worse than neither, so the queue does the one job it can do exactly right: apply what each file already claims about itself.

To see the reasoning behind the repair before running it on forty files, open one on the orientation page, which reports what it found and lets you choose. The workflow for a scanner in particular is set out in the explainer.