Try a quick experiment. Start a large batch job in your current resize or watermark tool—thousands of images if you have them. Open Task Manager while it runs.
If the app is browser-based or an Electron shell, you will often see one core pinned while the rest of the CPU graph looks bored. On an 8-core machine, that can mean overall utilization stays in a modest fraction of theoretical throughput. You paid for parallel silicon; the stack may not be using it.
That gap is a big part of why we built the Automata Asset Pipeline in Rust and Tauri: move CPU-heavy work onto OS threads, keep the UI responsive, and stop treating file work like a fragile webpage.
Why many “desktop” apps stay single-threaded in practice
Electron and Chromium shells
Electron bundles a Chromium-based runtime with your app. That helps teams ship cross-platform UI fast—but users pay in RAM, startup cost, and often in parallelism: JavaScript-centric architectures frequently serialize heavy work in ways that underuse cores.
Web Workers exist, yet building high-throughput, disk-backed image pipelines entirely in worker land is nontrivial. The result is familiar: one file at a time, one hot core, everyone else idle.
Pure browser SaaS
Browser tools add upload and download to the same bottlenecks. For small sets, that can feel fine. For thousands of originals, network latency and quota behavior dominate—and you may be copying bytes you never wanted off-disk in the first place.
What Rust and multithreaded processing change
Rust compiles to machine code—no VM in the loop for hot paths, no GC pauses in the processing core. Concurrency patterns (for example work-stealing pools) can keep cores busy while respecting memory bounds: decode N images at a time, not “the whole folder at once and hope.”
In the Automata pipeline, OpticBatch handles image processing and MetaForge handles metadata. Throughput depends on available threads, storage, file formats, and thermals.
A realistic benchmark framing (5,000 files)
Imagine 5,000 outputs after an event: rename for delivery, web-resolution JPEGs, and watermarks on those derivatives.
A typical sequential / web-tech path
Wall-clock estimates vary widely by preset, codec, disk class, and thermals—but a pattern we see often looks like:
- Renames: minutes of single-file work in Explorer-class flows or scriptless GUI stacks.
- Resize and encode: tens of minutes when each image is processed one-after-another on limited parallelism.
- Watermark composites: another stretch of per-file work.
Total can land in the roughly 45–80+ minute range on common studio laptops when the tool does not parallelize aggressively—or when the workflow is partially network-bound.
Image processing with OpticBatch
OpticBatch handles the resize and watermark steps with multi-core decoding and encoding. File renaming is a separate step in this workflow.
Measure the image-processing stage on your own files and presets. A faster image stage does not establish a speedup for the entire delivery workflow.
Safety at speed: why atomic writes matter
Batch image tools need to preserve client assets while processing them. Useful implementation patterns include:
- Atomic writes—write to a temp path, then commit so interrupted jobs do not half-overwrite originals.
- Bounded concurrency—avoid exhausting RAM when mixed RAW/JPEG folders balloon peak memory.
- Work-stealing scheduling—keep workers busy when file sizes differ (as they always do in real dumps).
Rust’s ownership and concurrency tooling make these patterns easier to enforce by design than in ad hoc parallel scripts.
Compound time savings
Saving an hour on a single big batch is nice. Saving an hour ten times a month is multiple working days per year returned to billable creative work—or to going home on time.
Unlike metered cloud “accelerators,” local throughput has zero marginal cost for the next folder: the hardware is already purchased.
Why not only CLI tools?
ImageMagick, ExifTool, and friends are powerful. They are also not products for everyone: weaker guardrails for destructive mistakes, less interactive reassurance, and composition across multiple CLIs costs script time many photographers should not owe.
OpticBatch packages resize, convert, watermark, and related batch transforms into a desktop UI on top of the same category of muscle without asking you to live in a terminal. Pair it with MetaForge when metadata scrubbing belongs in the same delivery story.
If you want multi-threaded batch image work that actually uses your CPU cores, a local desktop pipeline is available in
Get it fromMicrosoft
Tauri: Rust back end, light shell
OpticBatch uses Tauri—Rust back end, system webview front end—so installs stay lean compared with bundling a full Chromium per app. Heavy work stays off the UI thread; the UI stays responsive while workers saturate cores for image math.
Get OpticBatch on the Microsoft Store
Perpetual license · local-first desktop utilities
To saturate local cores for resize, convert, and watermark jobs without cloud queues, a one-time desktop license starts with
Get it fromMicrosoft