An Image Editor with No Actions

Why non-destructive editing tools are not only more powerful, but EASIER to use, and why non-destructive editing's full payoff doesn't occur until it's total and uncompromising.

I'm going to show that non-destructive editing operators are not only fundamentally better and more powerful, but are also massively EASIER to use. And whether you love or hate 2d node-canvas spaghetti, I'll tell you right now, this is not where we are going.

Destructive tools like Photoshop make the user memorize and use destructive-action construction sequences to get where they are going. Everything is: assemble-products, perform destructive action, if wrong: undo and repeat until correct, flatten into result, move on to next part of the construction. In order to assemble a final output, the user has to mentally work backwards through all the things they will need to do to get there  --- and then start at the beginning! It's like learning to recite the alphabet backwards. How many of you can do that? And Photoshop is many times more complicated than the alphabet. 

However, there is an easier way. My tool has no "actions". There are no configure dialogs where you "Commit" and change the underlying data. I don't need "Photoshop Actions" to replay a sequence, because everything is live through the pipeline always. I have not even added a flatten feature (*yet). And yet most things *feel* mostly layer-like. It's like... better layers.  (* I will eventually add Flatten, but destroying the chain will be your choice, never required to get something done)

Non-destructive operators allow the user to explore and learn. Building something and refining it step by step. One can assemble the final production in any order, because every part of the construction remains live at all times. If you want to mask something, you just create a mask operator "thing", and look at it, and see what it needs, and supply something to its inputs, and see what it produces. The learning becomes EXPERIENTIAL instead of a library research project and memorization.

Below is a quick screenshot of my new easy to use image creation tool.

This sample workflow is taking an input image that's a color "PDF" and converting it to black/white, then piping it into 3 different mask operators (one for each letter) over three different input images, each to fill one of the letter shapes, then merging together the three composed letters into the final image. 

In Photoshop or Affinity, this requires destructive actions and/or duplicating image layers, which breaks the live connection. When you want to change early inputs, you get to repeat the steps. 

In my tool, you can edit any part of the entire image flow, including the original PDF mask image, and everything updates live. You can't do that in Photoshop at all. You can do this in an image compositor, like Nuke, or Mari, or Blender - but then you're working with 2d node-graphs, not something that feels like layers.

My tool is not the first to use non-destructive editing. 

Even among destructive tools, the availability of non-destructive contexts is growing. Photoshop has vector shape layers. Pixelmator has a set of non-destructive tools, and Affinity even claims "most" things can be done non-destructively. However, the billing here is deceptive.

Having a vector shape layer in Photoshop, or a non-destructive tool layer in Affinity, does not actually get you non-destructive composition — because the next tool doesn't take the result of a live pipeline, it takes an image. To compose non-destructively, every operator has to accept live results, not flattened ones. Your whole composition is only as manipulatable as its weakest link. Make one destructive flatten, and edits across the boundary are broken.

My tool uses ONLY non-destructive editing. There is no need to "Flatten" anything, ever. You can just keep building and constructing, keeping everything live, always. 

My tool is also not the first to do that. There is a family of node-based image tools including Nuke, Silhouette, Mari, Blender compositing, even ComfyUI. However, they all arrange operations onto a 2d Node canvas. This is powerful when the workflows get very large. However, it's also somewhere between inconvenient and terrible when one wants their screen real-estate to be focused on the art, not the node spaghetti wiring.

A node-based workflow in ComfyUI:

My image editing tool is trying to free node-based power and ease of use from the spaghetti.

My first screenshot was a fully node-based composition program, and you can see, it looks like a traditional layer stack. Here is a simpler one. This is a Vector shape and a text shape, which is then piped in as a mask layer for a loaded image. 

The blue line represents the mask-image pulling its source from out-of-flow. The bright white underline on the koyote-ramen.jpg image says that this layer is not compositing with the chain below. That's it. Everything is live.

I can select and edit the vector shape layer live, while looking at the base vector shapes, or while looking at the final composition. Everything is saved in the file and editable at any time. No flattening.

My tool has a ways to go before it's going to handle practical everyday workflows, because everyone tends to have their favorite pet features they like to use. However, I'm convinced that when I am able to add the majority of features, it will not only be expectedly more powerful for having a non-destructive node-compositing workflow in a layer-shaped package, but it will also be easier to use because of it.

 Will AI and Automation cause us to lose the ability to operate the known world? Is this Wall-E on the horizon? It's a difficult question to answer. However, lets start by consulting history.

• Plato, ~370 BC. In the Phaedrus, Socrates has the Egyptian king Thamus reject the invention of writing: it will produce forgetfulness, because people will trust external marks instead of their own memory, and it will give them the appearance of wisdom without the reality. Outcome: he was half right. Oral memory feats (reciting the Iliad) genuinely vanished as a common skill. And writing enabled everything else. The skill was lost; the capability grew; the cost landed on a specific faculty nobody chose to keep.
• The printing press, 1400s–1500s. The abbot Trithemius wrote In Praise of Scribes (1492) arguing monks should keep copying by hand — printed books wouldn't last, and copying was how you learned the text. Conrad Gessner warned of information overload. Outcome: scribal skill died within a generation; literacy exploded.
• Calculators and arithmetic, 1970s. The debate is documented at length and had an unusually clean natural experiment: mental arithmetic fluency measurably declined, and the response was to redefine what math education was for (estimation, reasoning) rather than to ban the tool. Outcome: Our modern world is built around calculation and computation, and math and science advances have skyrocketted, including the creation of AI. 
• Bainbridge's "Ironies of Automation" (1983). Her argument is precise: automation takes over the easy, frequent cases, so operators stop practicing; but automation hands back control exactly in the rare, hard cases — so the human must handle the hardest situations with the most atrophied skill. Air France 447 (2009) is the canonical instance: autopilot disconnected in a storm, and a crew who had rarely hand-flown at altitude stalled a healthy aircraft into the ocean. Outcome: Atrophied skills have been replaced with systems and backups systems and checklists and redundancy. Judged by fatalities per passenger-mile, commercial aviation is among the safest human activities. 

The pattern across all of them: the tedious skill embedded in doing the thing disappears, because nobody assigns it practice and it adds little over the automation. What replaces it is not the old skill revived — it's a new one, shaped by the tool's failure modes: using the tool, diagnosing it, building the checklists and backups around it. The real cost of every automation in history has been the same: the lag between adopting the tool and learning to use it well. Aviation paid that lag in crashes. We get to pay it in something cheaper, if we name the skill early.

My hope? We are headed to a future with more opportunity for creative challenge than ever, because AI is compressing more tasks into automation of the tedious than any previous technology, ever, by a wide margin. Which will leave our human cycles for the truly value-add creative work in the new frontiers beyond current AI technology. And if you think that frontier does not exist, we will miss you on the other side.

TUNES is a Useful Nevertheless (NOT?) Expedient System

I want to take a moment to acknowledge a piece of digital history that's on the verge of evaporating. As early as the mid-1990s (when I was in college), I read about this ambitious TUNES is a Useful NOT (*) Expedient System aspirational project. The core-idea as I saw it, was a user-centric software system that let the user express what they want to happen, and the software would then deal with the details. 

For most (if not all) of the tunes.org history, the project was merely aspirational. François-René Rideau's  dream of how software could adapt to people, instead of people adapting to software. And *that* mentality, is what became the most enduring legacy of TUNES in my mind over the many decades I've worked in technology.

As I recall, there was a motivating user-story about organizaing a music or CD collection, which probably was to feed into the TUNES namesake. Where the user simply expressed commands to the system, and it dealt with the details of organizing the data, searching it, presenting it, etc.

While one might think that only now in the era of AI are we getting close to the vision, there are many layers to this idea that have to be tackled as technical problems long before AI can be incorporated. Inside the project David Manifold <dem@tunes.org> got involved and did experimental work on bottom up practical elements, attempting to undestand how TUNES would ever come to be.

However, those of us inspired by TUNES carried the torch of the dream into our own lives and in our own ways. 

I personally became fascinated with reflective and self-introspective language systems like Smalltalk and the SELF environment. I also became fascinated with the technical callenges of automatically optimizing databases. Despite most RDBMS systems still using b-tree based storage, any who have worked with them understand how little write throughput they have because of b-tree write amplifcation. If we are to achieve automatically optimizing databases, it will likely be through write-optimized storage systems, because automatic optimization means a constant write load of reorganization. Modern storage engines like Bigtable, Spanner, LevelDB, Cassandra, and Cockroachdb are based on row-split log structured merge based storage, which has orders of magnitude more write througput while asymmetrically only giving up a little read throuput.

Even today, I dream of a day where software systems such as TUNES exist, and deliver the dream none of us know we have. The dream of a software system that does what the user wants. Depicted in movies like Star Trek, aspired to by Richard Stallman's dream that GPL'ed software would return control to users (though IMO it hasn't).

Perhaps now that we have AI, both to embed into the system, and to help write it, we can finally start to see someting approaching the TUNES dream come into existance. Lets make sure it happens in the promise of user-soverign control, rather than the software balkanization for revenue that has marked most of the software industry's pattern to date.

(*) I recall TUNES described as "NOT expedient", as a way to explain that the focus was utility not necessarily performance. Now I see it described as "Nevertheless expedient", and I'm not sure if that transformation happened in the project, or in my own mind. I the framing in my memory, as it was offering the audiciousness of "what could we do if performance wasn't an issue?"