Download Latest Version SageThumbs2K-Setup-3.10.0.exe (15.2 MB) Google Add to Preferred Sources
Home / v2.3.1
Name Modified Size InfoDownloads / Week
Parent folder
SageThumbs2K-Portable-2.3.1-arm64.zip 2026-08-22 22.1 MB
0
SageThumbs2K-Portable-2.3.1.zip 2026-08-22 23.8 MB
0
SageThumbs2K-Setup-2.3.1-arm64.exe 2026-08-22 12.5 MB
0
SageThumbs2K-Setup-2.3.1.exe 2026-08-22 13.8 MB
0
README.md 2026-08-22 11.4 kB
0
SageThumbs 2K 2.3.1 source code.tar.gz 2026-08-22 5.3 MB
0
SageThumbs 2K 2.3.1 source code.zip 2026-08-22 5.7 MB
0
Totals: 7 Items   83.2 MB 0

TL;DR

🆕 New

  • Quick preview scrolls continuously through multi-page PDFs

🩹 Fixed

  • Wide CSV files are readable and much faster in preview
  • Large CSV or database files no longer hang the preview
  • Hasselblad RAW photos now thumbnail much faster
  • Arrow keys always move between files in Quick preview
  • Scanned DjVu pages no longer lose their photographs
  • Tiny built-in DjVu previews no longer stretch to big tiles
  • Large layered GIMP files thumbnail faster and reliably
  • Music files now show their real album art
  • Some camera RAW files no longer thumbnail black or tiny
  • InDesign documents no longer thumbnail as a torn strip
Read more: everything in 2.3.1 ### Added - **The Space-bar Quick preview now scrolls continuously through a PDF, instead of showing one page at a time.** Roll the wheel, or use the up and down arrows, and the document flows past the way it does in a real reader: the end of one page, the gap, then the start of the next. Page Up and Page Down jump a screenful, Home and End go to the ends of the document, and the page counter in the title bar follows whichever page you are actually looking at. Ctrl and the wheel still zooms, and left and right still move to the next and previous FILE. Pages are drawn as they come into view, so a long document opens as fast as it always did rather than making you wait for all of it, and the scroll bar is the right length from the very first frame because the page sizes are read before anything is drawn. ### Fixed - **Wide CSV files were unreadable in the Quick preview, and painfully slow with it.** A spreadsheet export with a lot of columns was squeezed into the window however many columns it had, so a 201-column file got about six pixels per column and every value came out as a vertical stack of single letters: the header literally read "c/o/l/0" downwards. That is also why it was slow, because the preview then had to lay out every character of every cell to work out how tall each row was. Columns now have a readable minimum width, and any that do not fit are reported under the table ("+29 more columns not shown") instead of being crushed. Arrowing through a folder of CSVs is between **11 and 27 times faster**: a 5 MB, 6,666-row, 80-column file went from **49 seconds to 1.8**, and nothing in a folder of fifteen now takes more than two seconds. Narrow tables, and Markdown tables generally, look exactly as they did. - **The Quick preview could stop responding on a large CSV or database file, so that Windows called it "not responding" and you had to end the task.** It was not crashing: the table was being laid out on the same thread that answers Windows, and on a big enough file that took longer than the few seconds Windows waits before declaring a window hung. The table work above is far quicker now, so it stays responsive. Database files (`.db`, `.sqlite` and friends) are drawn by the same code and were affected the same way; a 7 MB one went from over five seconds to well under one. - **Hasselblad RAW photos took well over a second each to thumbnail.** A `.fff` or `.3fr` file carries a ready-made preview picture, but SageThumbs was ignoring it and decoding the entire raw sensor image instead, every time. It now uses the camera's own preview whenever that preview is genuinely large enough for the size being asked for, and decodes properly when it is not. A `.3fr` thumbnail went from **1191 ms to 22 ms** at Explorer's medium icon size and from 1218 ms to 28 ms at large; a `.fff` went from **1635 ms to 44 ms**, and even the biggest view from 1663 ms to 175 ms. The picture is the same one earlier versions showed, and it is slightly sharper, because it is the camera's preview at its own size rather than a shrunken full decode. This does NOT bring back the black-square bug fixed earlier in this release. Some cameras, Kodak among them, store a blank placeholder in that slot rather than a real preview, and being large is not the same as having a picture in it. The preview is now checked for actual content before it is used, and a blank one is ignored exactly as it is today. - **In the Space-bar Quick preview, a PDF with more than one page trapped the arrow keys.** The left and right arrows turned pages instead of moving to the next file, and because paging stops at the first and last page, there was then no key at all that would take you to another document. The only way out was to close the preview and open it again on something else. Left and right now always move between files, on every kind of content, and pages are turned with up and down or Page Up and Page Down, the same as Quick Look on a Mac. Single-page PDFs were never affected, which is why this went unnoticed for so long. - **Scanned DjVu documents could thumbnail as a plain grey rectangle, or lose every photograph on the page.** DjVu stores a page as two layers: the text and line art on top, and a compressed photographic background underneath. When a page was larger than roughly 4200 pixels on its long edge, which is any ordinary letter or A4 page scanned at 400 dpi or better, the background layer was dropped and never drawn. On a photo-only DjVu, which has nothing but that layer, the result was a tile of flat grey with nothing in it at all. On a normal scanned page the text still appeared, so it looked fine at a glance while every photograph on it had quietly vanished. Both are fixed, at every page size. - **DjVu files that carry a built-in thumbnail showed that thumbnail even when it was far too small.** Some DjVu files store a small preview picture inside them, and every program that writes one caps it at 128 pixels. SageThumbs used it whatever size had been asked for, so Explorer's large-icon view got a 128-pixel picture stretched up to fill a 768-pixel tile, and opening the file in Convert or Resize gave you 128 pixels of a page that might be five thousand. It is now used only when it is genuinely big enough for what was asked, which keeps it nearly free for the small icon and list views and draws the real page for anything larger. - **Large layered GIMP files took up to ten seconds to show a thumbnail, and very large ones showed nothing at all.** SageThumbs was building the whole picture at full size before shrinking it down to a tile: a 12000x12000 file needed half a gigabyte of memory to produce a 256-pixel thumbnail, and a 15-layer file spent ten seconds on work that was then thrown away. It now builds the picture at the size actually being asked for, which is **ten to seventeen times faster** on those files, and reads each piece of the file at its real length rather than a worst-case guess. The thumbnail itself is unchanged, pixel for pixel. Opening a GIMP file in Convert or Resize still gives you the full-size image. - **Music files could show a blank or tiny thumbnail instead of their album art.** A tagged audio file is allowed to carry more than one picture, and plenty do - the sleeve plus a small "file icon" some tagging programs add, or a leftover from whatever wrote the file first. SageThumbs took whichever picture came first in the tag, so the sleeve lost to anything sitting in front of it. It now looks for the one actually marked as the front cover, and picks the largest when a file has several. Applies to every audio format we read art from: MP3, FLAC, WAV, M4A, OGG, Opus, WMA, APE, WavPack, DSD and the rest. - **Some camera RAW photos thumbnailed as a black square, and others from a postage stamp.** Several RAW formats are TIFF files underneath, and they keep a small preview at the front with the real photo further in. The fastest of our decoders reads only that front section, so it was answering with the preview and nothing better ever got a turn. A Kodak .dcr came out solid black, because the front section of those files is a blank placeholder, and .3fr, .erf, .fff and .kdc were being blown up from previews as small as 96 pixels wide. These files now say plainly when their opening section is only a stand-in, and we skip straight to a decoder that reads the real photo. Nothing that produced a thumbnail before has stopped: the small preview is still there as a last resort if no other decoder can read the file at all. **Converting, resizing or reading the details of one of these now gives you the real photo** rather than the small preview, which for .3fr means 7247x5444 instead of 320x240, and for .kdc means 768x512 instead of 96x64. Also affects .nef, whose thumbnail already looked right because its preview happened to be big enough for a tile. - **Adobe InDesign documents and templates thumbnailed as a thin strip of the page over a blank grey panel.** InDesign keeps the page preview as a picture tucked inside the document's metadata, but an `.indd` file is a database rather than a straight run of bytes: every save writes a fresh copy of that metadata and leaves the older copies behind in the file, torn up and partly overwritten by whatever else got saved on top of them. SageThumbs was reading straight through those leftovers, so unrelated pieces of the document ended up glued into the middle of the picture. The result still looked like a valid image from the outside, and it was the biggest one in the file, so it was the one that got picked - and it drew as the first few rows of the real page followed by nothing. It now stops reading a preview the moment the file stops being metadata, and it only accepts a picture that is genuinely complete from beginning to end. Documents saved without a preview (InDesign's "Save Preview Images with Documents" setting turned off) show the normal Adobe icon, which is the correct outcome and was already the case.

Verified installer

  • File: SageThumbs2K-Setup-2.3.1.exe
  • Size: 13797784 bytes

  • SHA-256: 206ea4c2109777a4a8b61ba9105216f85f8e18ee48449a08b6190f35faf85931

  • ARM64 installer: SageThumbs2K-Setup-2.3.1-arm64.exe

  • ARM64 SHA-256: 3ecb3ff087465faa7c38b007245d9a3545c5f152d531016fbe20d2578fa049a2

Portable (no installer)

Extract and run. Nothing is installed, nothing goes in the registry, no admin needed. Settings live in SageThumbs2K.ini next to the exe.

You get the app and the command line tool: settings, convert and resize, quick preview, screenshots, OCR, the colour picker and the folder tools.

Explorer thumbnails and the classic right-click menu work too. Turn them on with st2k register, or the button in Settings under Advanced. That registers the handler for your user account only: no installer, no administrator rights, nothing written machine-wide. st2k register --off undoes it, and you should run that before moving or deleting the folder, otherwise Windows is left pointing at a file that has gone.

Three things still need the installer, because Windows only accepts them registered for the whole machine: the Explorer preview pane, the Details pane columns, and the Windows 11 right-click menu (the compact one).

  • x64 portable: SageThumbs2K-Portable-2.3.1.zip

  • x64 portable SHA-256: 9c4caa692dc0f89279af3c13293a11f8b22e9f886efc5510fe6e090cfa4b4aac

  • arm64 portable: SageThumbs2K-Portable-2.3.1-arm64.zip

  • arm64 portable SHA-256: d9866d638ce0f5f7355cc941a9d1d2beddcd39313ced26e82cc8846fd82f4c7d
Source: README.md, updated 2026-08-22