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, Reforge, and MetaForge aim to scale work with available threads at runtime—more cores should mean more parallel throughput, bounded by disk and thermals like any real system.
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.
A parallel pipeline with Reforge + OpticBatch
Same job, different architecture:
- Reforge for batch renames with atomic, preview-first execution—large trees often finish in seconds to low minutes depending on rule complexity and storage latency, because rename operations can be parallelized without mangling originals mid-flight.
- OpticBatch for resize + watermark with multi-core decoding and encoding—often on the order of a few minutes to single-digit minutes on modern 8-core-class machines in our internal testing; 16-core workstations can improve further until disk or thermal limits bite.
Total wall clock frequently collapses into a small number of minutes versus nearly an hour—call it large double-digit percentage savings rather than a guaranteed “always 80%” on every machine. Your results will differ; treat numbers as orientation, not a spec sheet.
Safety at speed: why atomic writes matter
Faster batch work is worthless if it corrupts client assets. Reforge and OpticBatch emphasize patterns like:
- 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 OpticBatch on Microsoft Store
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
OpticBatch — Microsoft Store · Reforge — Microsoft Store · Automata Labs publisher (MetaForge)
$4.99 per app · 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 OpticBatch on Microsoft Store