If you scan to TIFF, this update is for you. Until this week a 45 megapixel TIFF took about 20 seconds to appear in AutoCropper, and on a busy computer the largest ones failed with a "damaged or unsupported" message that was not true. Now the same file is on screen and ready to crop in about 3 seconds, uses hundreds of megabytes less memory, and the false error is gone.
Who this affects
TIFF is what most flatbed scanners save when you ask for the highest quality, and it is what Lightroom exports when you want a lossless file. A 16-bit TIFF of a full scanner bed at 600 DPI is around 45 megapixels and 270 MB. Those are exactly the files people bring to AutoCropper when they are digitizing a family archive properly, and they were the slowest thing you could upload. Over the last two months, 13 of the 14 longest waits for a first image in AutoCropper were TIFF batches.
JPEG and PNG uploads are not affected by this change. They were already fast, and they still take the same path.
Why TIFFs were slow
AutoCropper runs entirely in your browser, so every file has to be decoded there before you can see it. For TIFFs we used a general-purpose decoding library. It is thorough, which is its strength: it handles every variant of the format. But it does that by unpacking the whole page into memory, then converting it a second time into the layout the screen needs, then drawing it. For a 45 megapixel 16-bit page that meant close to a gigabyte of temporary memory and 13 seconds of work, and it all ran on the same thread that draws the page, so the tab froze while it happened.
The failure was a separate bug hiding behind the slowness. After decoding, the converted page was turned into a very long text string and read back again, a step that needed a second copy of the whole image. When the browser could not find room for that copy, the conversion failed, and the app reported the file as damaged. It was not. The same file would convert fine a few minutes later.
What we changed
Three things, over two updates.
The work moved off the main thread. TIFF conversion now runs in a background worker, one per file, which is released the moment the page is done. The tab stays responsive while a big file converts, and the memory a page touched is returned immediately instead of lingering.
Uncompressed TIFFs skip the decoder entirely. Most scanner and Lightroom TIFFs are stored uncompressed, which means the pixel data in the file is already in the order the screen wants. The converter now recognizes those files and paints them straight from the file bytes, a few hundred rows at a time, with no library and no full-page copy in between. Compressed TIFFs, whether LZW, Deflate or PackBits, are read the same way, a strip at a time, and JPEG-compressed TIFFs are handed strip by strip to the browser's own JPEG decoder, which used to be a file we could not open at all. Only the rare layouts, planar, palette and fax-compressed files, still go through the library, so nothing that opened before stops opening. Every path produces identical pixels, and our tests check that on every build.
The thumbnail is made while the page is still in hand. The converter now produces the preview and detection images at the same time as the full page, instead of the app decoding the converted file a second time to make them. That alone was two and a half seconds per file.
The numbers
Measured on a 45 megapixel, 16-bit, 272 MB Lightroom TIFF, three runs each, in a controlled test environment. Times are from the moment the file is dropped.
| What you wait for | Before | After |
|---|---|---|
| File converted | 16 seconds | 3 seconds |
| Thumbnail on screen | 19 seconds | 3 seconds |
| Ready to crop | 20 seconds | 4.5 seconds |
| Peak browser memory | 1,380 MB | 970 MB |
| A batch of 2 TIFFs and 5 JPEGs, fully loaded | 31 to 38 seconds | 6 to 8 seconds |
The test machine is slower than most desktops, so your absolute times should be shorter. The ratios should hold, because the work that was removed is the same work on any machine.
The one trade-off
AutoCropper keeps a working copy of each converted page for the rest of your session, and your exported crops are cut from it. That copy is now a JPEG at quality 95 rather than a lossless PNG. It converts three times faster and takes a quarter of the memory, and at that setting the difference from the original is not visible. It is the same quality setting HEIC photos and PDF pages have always used in AutoCropper. If your archive workflow needs a byte-for-byte lossless chain from scanner to crop, keep your original TIFFs, which AutoCropper never modifies, and export your crops as PNG.
What to expect
Drop your TIFFs in the same way as before. The first thumbnail should appear within a few seconds, the page should stay responsive while the rest convert, and a batch that used to be worth walking away from should be ready before you have.
If a very large TIFF still fails to convert, the message now tells you the truth: the browser ran out of room. Closing other tabs or heavy applications and trying that file on its own will usually clear it, and exporting 8-bit rather than 16-bit TIFF from your scanning software halves the size with no visible loss for prints.
If you scan photos and have not tried AutoCropper on a TIFF batch lately, this is a good week to give it another go. And if something is still slow for you, tell us which scanner or software made the file. That report is what made this update happen.