imgplex is a node-based batch image workflow creator and processor. All the processing is handled by ImageMagick, imgplex just makes the string of commands needed to pass onto ImageMagick.
Disclaimer: imgplex has been developed with help from AI tools. But this isn’t a ‘vibe coded’ project - AI didn’t write all of the code, and a lot of thought, research, and planning went into development of this application to keep the development properly planned and organized. A lot of effort has also gone into keeping the UX and batch processing performance optimal. This series of blog posts will describe the development process of imgplex.
The why
In game development we do a lot of texture processing as part of the content pipeline, whether it is creating textures or processing textures from asset packs. As a technical artist I’ve made a bunch of tools of various sorts to automate the process as much as possible, but the use cases are far too different to be covered effectively by a few tools.
While with the advent of AI tools it has become easier to make purpose built tools to solve a specific problem, it rapidly becomes a jumble of various tools that do just one job, are scattered, and not documented.
I’ve used ImageMagick as a solution for some of these problems. It is incredibly powerful, and you can pipe commands to make complex operations happen in one go. But it has the limitations of being a command line tool: scary for non-technical people, and no preview stage before processing. A lot of image processing we do is visual in nature, and command line tools don’t give interactive preview controls that artists love to use. I also want something artists can use independently, without needing a technical person or an AI tool.
The what
I decided to build the tool on top of ImageMagick since it can do literally everything we need in terms of image processing. The idea was to use a node based editor to generate ImageMagick commands. Node based editors are common in game development workflows, we have node based editors for shaders, VFX, and procedural content that artists are already comfortable with (Shader and VFX graph, Houdini, Substance Designer, Blender’s geometry nodes etc).
I also happen to have a lot of experience with image editing and node based tools as a result of my game development career, and it seemed like a natural fit.
A node based image processing workflow editor would be easy to extend as well: a node is just a representation of the ImageMagick command. I also decided that the node definitions should be kept as JSON files, so that users can add nodes without the application needing a recompile.
There’s another advantage too to this approach, since the tool is used to define just the workflow and not handle image processing, I can run the processing headlessly in automated workflows: just export the commands from the workflow to a script.
The how
With the plan decided, I started research on the tech stack to make the tool. The core tension was native performance vs development speed: I wanted to build the tool, not fight the tooling.
I evaluated several approaches:
- C++ with Qt was the obvious professional choice: great node editor libraries, excellent performance. But learning a new language and framework simultaneously (I’m experienced with C# and Python, but not much with C++) alongside a complex project was a recipe for never shipping anything.
- Tauri looked promising: lightweight, Rust backend, web frontend. But two concrete blockers killed it: an IPC bottleneck where serialising image data as strings benchmarked at ~200ms per 3MB; and the sidecar lifecycle complexity of managing a separate processing process.
- I gave serious thought to using Godot: GPU shaders for preview would be great. It was rejected because desktop UI infrastructure (inputs, dropdowns, file dialogs) would take weeks to build.
- Electron won. It does get criticism for bundle size and memory overhead, but for a professional tool that will handle gigabytes of image data, a 200MB install and some extra RAM usage are irrelevant. What matters is: consistent rendering across platforms, Node.js built in (no sidecar needed), and a mature ecosystem. I could get something working really quickly and iterate from there.
- For the node graph editor, Svelte Flow beat out LiteGraph.js - the library used by ComfyUI - because LiteGraph’s original repo hasn’t been maintained in years and ComfyUI operates off a divergent fork. Svelte Flow is MIT-licensed, actively maintained, and integrates natively with the UI framework.
- For the UI framework, I chose Svelte 5 over React: less boilerplate, no virtual DOM, and native integration with Svelte Flow’s
$state.rawrequirement for graph state.