dezoomify-rs reassembles the tiles behind a zoomable image

Why a tiled image needs a downloader at all

The problem is stated in one paragraph of the readme, and it is the whole reason the project exists.

Some webpages present high-resolution zoomable images without a way to download them. These images are often tiled, which means the original large image has been split into smaller individual image files called tiles. The only way to download such an image is to download all the tiles separately and then stitch them together. That process can be automated by a tiled image downloader.

So this is a category of tool that exists because of how images are served on the web. A museum scans a painting at 30000 pixels wide, the web platform cannot display that, so the server cuts it into a grid of tiles and a viewer assembles the grid on demand as you zoom. The user sees one picture. The network sees thousands of small requests. And a person who wants the picture cannot save it from the browser.

The readme is careful about the scope, saying that the goal of this project is not to replace the traditional dezoomify, which is an online tool that is probably the most common tiled image downloader and is very easy to use. The distinction it draws is that some images are so large that they cannot be efficiently downloaded and displayed inside a web browser, and that sometimes a website tries to protect its tiles by refusing access to them when certain HTTP headers are not set to the right values.

dezoomify-rs is a desktop application for Windows, macOS and Linux that does not have the same limitations as the online zoomify, and it lets you choose between several output image formats, whereas in dezoomify you can only save the image as PNG.

The audience is a person who needs the full resolution of an image they can see on a screen, which in practice means researchers, archivists and anyone working with museum collections.

One dezoomer per image service

The core of the design is a set of dezoomers, each backed by a dedicated implementation for one image service. The list in the readme is long and specific, and it is the clearest picture of how fragmented this problem is.

Google Arts and Culture supports downloading images from artsandculture.google.com. The zoomify dezoomer handles the popular Zoomify format. deepzoom supports Microsoft's DZI format, which is often used with the seadragon viewer. IIIF supports the International Image Interoperability Framework format. Then there is a run of less common ones: Krpano for the krpano panorama viewer, IIPImage for the iipimage format, XLimage for XLimage servers, TopViewer for Picturae Memorix image services, FSI for Neptune Labs FSI Server images, LizardTech for LizardTech ImageServer services, VLS for Semantics Visual Library Server viewers, Hungaricana for Hungaricana ECW image services, WMTS for Web Map Tile Service capabilities documents, ArcGIS for cached ArcGIS MapServer services, and pnav for crop-based pnav image services.

Then the two escape hatches. The generic dezoomer is for when the tile URLs follow a simple pattern, and the custom dezoomer is for advanced users, where you can specify a custom tile URL format that can contain multiple variables. The readme says this gives you the most flexibility but requires some manual work, which is the correct description of a configuration file with a template in it.

The number is the point. A tiled image service is not a standard, it is a family of near standards, and a downloader that only handles the two most common ones will fail on the first museum site you try. Seventeen dezoomers is what it takes to have a good hit rate, and the custom dezoomer is the escape for the eighteenth.

The output format is chosen by the file extension

The format selection in dezoomify-rs is unusually elegant, and it is worth understanding because it decides whether your download succeeds at all.

The format is determined by the name of the output file. Entering dezoomify-rs http://example.com/ my_image.png on the command line creates a PNG image, and each encoder has its own set of features and limitations.

PNG images are compressed losslessly, so the output quality is, very slightly, better than JPEG, at the expense of much larger file sizes. The PNG encoder can create very large images and is not limited by the available memory on your computer, and this format is chosen by default when the image is very large or its size is not known in advance.

JPEG is the most common image format, but JPEG images cannot be more than 65535 pixels wide or high. The JPEG encoder requires the whole image to fit in memory, and this format is chosen by default for images that fit within that limit.

All the formats supported by the image-rs crate are also supported.

And then there is IIIF as an output, which the readme recommends when the image is very large, multiple hundreds of megapixels, since most image viewers do not accept huge PNGs or JPEGs. If the output path ends with.iiif, a folder is created instead of a single file, with its structure following the IIIF specification, and a file called viewer.html is created inside the folder which you can open in your browser to view the image.

So the choice of extension is a choice of strategy. PNG for a lossless archive, JPEG for a normal picture you will open in anything, IIIF when the image is too big for a viewer to handle and the point is to keep it zoomable.

Memory, not disk, is the constraint on a big image

The two default format choices tell you the real limit of the tool, which is memory rather than time or bandwidth.

A very large museum scan at several hundred megapixels, decoded into memory, is a lot of bytes. The PNG path avoids that by streaming, and the readme is explicit that the PNG encoder is not limited by the available memory on your computer, which is why it is chosen by default when the image is very large or when the size is not known in advance. The JPEG path cannot do that, because the JPEG encoder needs the whole image in memory, so it is only chosen when the image fits, with the 65535 pixel limit on each side as the hard boundary.

And IIIF sidesteps the problem rather than solving it. Instead of producing a single huge file that a viewer may refuse, it produces a directory of tiles in the IIIF layout with a viewer.html that zooms in the browser, which is the same trick the source site was using.

That last option is the one to reach for when the goal is a zoomable archive rather than a single picture. It is also the one that makes the tile cache more valuable, because the output is then a set of files on disk rather than one object in memory.

The tool also keeps a tile cache, and this is the feature that turns an interrupted download into a resumable one. By default dezoomify-rs works entirely in memory, which is very fast, but the latest versions added the possibility of a tile cache. Launched from the command line with dezoomify-rs --tile-cache my_caching_folder http://myurl.com, it saves all the image tiles it downloads to the specified folder, and if the download is interrupted before the end you can resume it later by specifying the same tile cache folder. A tile cache also allows you to get the individual tiles if you want to stitch them manually.

That last point is a real workflow. For a large image, downloading the tiles to a folder and then stitching them with your own tools is a perfectly reasonable path, and the cache is the way to get the tiles out of the tool.

The readme says this project is no longer maintained

The first thing in the README is a caution box, and it changes the whole framing of the project.

It says dezoomify-rs is not maintained anymore, and that the new unified dezoomify v3 is entirely based on the old dezoomify-rs codebase and has its own command line interface, with a link to the beta site at dezoomify.ophir.dev.

That is a successor, not a replacement, and the difference in approach is worth stating. The v3 project is unified, which suggests one tool covering the format landscape rather than a set of dezoomers, and it has its own command line interface rather than the dezoomify-rs command and its options. The codebase is the same underneath, which is good news for anyone who has read the current code and wants to follow it into the new project.

The repository itself is not marked archived, and the last push was on 2026-09-17, with the newest release v2.20.0 published on 2026-09-04 and v2.19.0 on 2026-08-27. There is also a pull request build in the release list, pr-336-ac6b428, titled as optimised test builds, which suggests some work continued after the 2.x line was settled.

There is also a file in the repository root called no-tile-error.md, which is a good name for the kind of thing that needs writing down, and an AGENTS.md for tooling instructions.

So the practical guidance is straightforward. If you need this capability today, the current release works and the successor is where the work continues, and for anything involving images of museum collections it is worth remembering that the tool is a downloader and the rights in the images are a separate question that the software does not answer.

The Rust stack behind the downloads

The Cargo manifest shows how the work is done, and it is a modern async Rust project.

The crate is dezoomify-rs at version 2.20.0, edition 2024, with a workspace member dezoomify-core, and the comment in the manifest notes that root level cargo build, test, clippy and bench cover both crates. The core crate being separate is the reason the successor project could be built on the same codebase, since the format handling and the user interface are already split.

The async runtime is tokio with the full feature set, and reqwest at 0.13 is the HTTP client, configured with charset, gzip, http2, native-tls, system-proxy and zstd. The image side is the image crate at 0.25 plus a dedicated png encoder at 0.18, and zif-tiff is there for TIFF output. The command line is clap with derive, the progress display is indicatif, the sanitiser for file names is sanitize-filename-reader-friendly, and human-panic is there to turn a panic into a readable message rather than a stack trace.

There is a benchmark, criterion at 0.8, with a bench named local_dezoomifying and the harness disabled, which is the right way to benchmark a crate that does its own timing, and the dev dependencies include image_hasher for comparing images in tests and tempfile for the scratch files the tests need.

The repository also has a testdata directory, a tiles.yaml at the root that looks like the tile template configuration for the custom dezoomer, and the usual Cargo.lock and.cargo directory.

Editorial conclusion

dezoomify-rs is worth reading and using if you already have the current release and need one specific thing from it, a working Zoomify or IIIF stitcher that runs on Windows, macOS and Linux and can write a local IIIF folder for an image too large to open. It is the wrong thing to start a new project on, because the README states the project is not maintained anymore and that the unified dezoomify v3 is built on the same codebase with its own command line interface, so the successor is where new formats and fixes will land. Before you install it, check the release page for the binary for your platform or use brew install dezoomify-rs, and note that the last push was on 2026-09-17 with the newest release v2.20.0 from 2026-09-04.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. lovasoa/dezoomify-rs on GitHub
3. Project website
4. README
5. Releases