Skip to main content
All posts

7 min read

Piggybacking on ArtCraft: Why My Oma Apps Got Easier to Build

Six days after I started Omapix, an open-source Rust suite dropped that had already done half my work

  • Open Source
  • ArtCraft
  • Rust
  • Omarchy
  • Photography

This picks up where Building Omapix left off. If you haven’t read how I ended up on Linux, start with the Omarchy switch.

I created the Omapix repo on September 24th. Six days later, the team behind ArtCraft published a stack of brand-new repos: PhotoCraft, LightCraft, VectorCraft, FilmCraft, PdfCraft and more. Each one is an open-source, clean-room rebuild of a big-name creative app, written from scratch in pure Rust. A week later came WordCraft, GridCraft, DeckCraft and CADCraft, and on October 9th, FigCraft. By then the press had noticed (Techaeris covered the launch on October 7th), and you can browse the whole family on getartcraft.com/apps.

My first reaction was a sinking feeling. I had just started building a Photoshop replacement for Linux, and someone had shown up with a Photoshop replacement for Linux, plus Lightroom and Illustrator for good measure.

My second reaction, a day or two later, was that this was the best thing that could have happened to my projects.

Three apps, one workflow

Quick recap on what I’m building and why it’s three separate programs instead of one.

My photography workflow has always been three stages: cull, develop, retouch. I shoot a lot, especially portraits and groups where I’m bursting to catch the frame where nobody is mid-blink. So each stage needs to be fast, and each one has its own frustrations on Linux.

  • Omacull is for culling. I want to fly through a card dump on the keyboard without waiting for a single frame, and none of the existing open-source options felt quick enough for how many photos I take.
  • OmaLux is for raw development. My problem here is color. On Linux, whether it’s darktable or even LightCraft, my photos just don’t look right to me a lot of the time. I miss the colors I got out of Capture One and Lightroom.
  • Omapix is for retouching: a fast, keyboard-first editor built specifically around portrait work.

All three follow the same rules: keyboard-first, the shortcuts from the Adobe app they replace, and themed to match the rest of my Omarchy desktop. That last one matters more to me than it probably should. If I’m going to live in a tiling window manager all day, I want my photo tools to look like they belong there.

Omapix and PhotoCraft: same starting point, different goals

PhotoCraft is genuinely good. But it’s trying to be all of Photoshop, and I don’t need all of Photoshop. I need rapid editing for portraits.

That difference shows up everywhere. When I went through PhotoCraft’s code in early October, it had no AI retouching, no one-click frequency separation, no native Wayland pen input and no darktable round trip. Those are exactly the features Omapix is built around. Omapix ships local AI tools like Heal Blemishes, Smooth Skin, Lighten Under Eyes, Face-Aware Liquify and Body Reshape. Every one of those runs on my own machine and outputs an ordinary layer, mask or selection I can tweak by hand. No cloud, no account.

What makes PhotoCraft so useful is that it’s built much the way Omapix is: Rust, egui on wgpu, tiled images. Ideas move between the two codebases easily. So instead of reinventing everything, Omapix now borrows the parts PhotoCraft has already figured out:

  • Brush feel. PhotoCraft carefully measured how Photoshop’s soft round brush actually lays down paint. Omapix ported that measurement, and soft brushes finally feel right for dodging, burning and painting masks. Brush dynamics (size jitter, scattering, transfer) and the mapping for loading Photoshop .abr brush files came over the same way.
  • The Refine Edge brush in Select and Mask, the tool that picks up stray hair without eating into skin, is ported from PhotoCraft.
  • Content-Aware Fill started from PhotoCraft’s fill. I changed how it starts and how it matches patches, because real photos came out smeared, but it was a huge head start.
  • Upstream fixes keep coming. When PhotoCraft fixed thin selections ghosting in Content-Aware Fill, or fixed lost pen pressure on fast strokes, Omapix picked those fixes up too.

Borrowing doesn’t mean taking everything. PhotoCraft’s PSD library is nearly 11,000 lines. Omapix’s PSD writer is about 250 lines written from scratch, and I used PhotoCraft’s reader to check that its files came out right. Sometimes the most useful thing a bigger project gives you is a way to test your own work.

OmaLux and LightCraft: borrowing the engine, not the look

In my last post, I called OmaLux the “final boss” and planned to build it last. Raw development is hard: decoding raws, demosaicing, highlight recovery, a color pipeline, GPU shaders that match the CPU output. That’s the kind of thing that eats months.

LightCraft changed that plan. It’s a full Lightroom rebuild, way more than I want, and its interface is its own, not Omarchy’s. But it’s built in clean layers, and everything under the UI stands on its own. So OmaLux vendors the bottom of LightCraft whole: raw decoding (including the Sony ARW files from my A7 III), the color math, the develop pipeline and its GPU version. OmaLux builds its own top layer: Lightroom’s panels and keys, XMP sidecars instead of a catalog, and Omarchy’s theme.

Which brings me back to color. If LightCraft’s colors don’t look right to me, why build on it? Because the pipeline isn’t what bothers me. It’s where the default look starts. OmaLux builds its color around a camera match: it fits the raw’s color to the JPEG the camera itself produced, so the starting point is the look Sony’s engineers tuned instead of a generic profile. That fitting code is also lifted from LightCraft’s engine. LightCraft did the hard math. OmaLux just builds everything around it.

To be honest about where it stands: OmaLux is early. The engine is vendored, the window opens, and the test spikes run on real frames, but there’s nothing to develop with yet. Still, the engine work I’d budgeted months for is already done, and I haven’t written a single slider yet.

Omacull: nothing to replace, something to talk to

Omacull is the one project where ArtCraft didn’t change much. Nothing in the suite does what it does, so it keeps doing its own thing: no waiting between frames, Bridge-style pick and reject keys, burst stacks, eye-sharpness signals, and keeper suggestions that learn from my own picks on my own machine.

What ArtCraft did give it is somewhere else to send photos. Set LightCraft as the developer and Ctrl+E hands it exactly the frames you’re looking at, with stars and rejects carried over in a sidecar both apps share. darktable still works too. Even when you don’t borrow code, sharing file formats with a big project makes your small one more useful.

Omavec: the project I’m happy to shelve

There was a fourth project. I wanted a vector app that fused Figma and Illustrator: Figma’s frames, auto layout and components, plus the Illustrator tools people leave Figma for, like Shape Builder, Offset Path and variable-width strokes. One app for logos and screens.

I created the Omavec repo on October 8th. Its geometry was already built on VectorCraft’s crates. FigCraft landed on October 9th.

Between the two, my needs are covered. FigCraft is honestly good enough for interface work, and VectorCraft handles the detailed vector work I do when I’m making logos. Omavec’s repo still has a careful plan for what to port from FigCraft if I ever pick it back up. But the best outcome for a side project is sometimes finding out you don’t need to build it.

It was pretty good timing, all things considered. A few days earlier and I’d never have started. A few weeks later and I’d have rebuilt a lot of things that already existed.

Why piggybacking works

A few things make this easy instead of messy:

  1. Permissive licenses. The Craft apps are licensed MIT OR Apache-2.0, so their code can go into my GPL projects as long as the copyright notices come along.
  2. The same stack. Rust, egui and wgpu across the board. A port is mostly translation, not an adapter layer.
  3. Rules for borrowing. Every borrowed file says in a header comment where it came from and at which commit. Vendored code is pinned to a commit and re-synced on purpose, not followed blindly. The Craft repos move fast (LightCraft alone gets hundreds of commits a month), so I keep a running list of upstream changes worth pulling in before each milestone.
  4. An AI that reads code faster than I do. As with Omapix, I direct and Claude does most of the reading and porting. Going through a week of PhotoCraft commits, checking each one against Omapix’s code and porting the worthwhile ones is an afternoon, not a weekend.

The division of labor ends up being pretty natural. ArtCraft builds big, general apps that try to do everything their Adobe counterparts do. I build small, opinionated ones that only do what my workflow needs, look like the rest of my desktop, and let me skip the hard parts somebody else already solved.

I’m doing less of the work, and ending up with tools I actually use.

Check them out

All of it is open source on my GitHub:

  • Omacull: fast, keyboard-first culling
  • OmaLux: raw development on LightCraft’s engine
  • Omapix: portrait retouching
  • Omavec: the vector app, on the shelf for now

And if you want to see what I’m building on top of, the whole Craft suite lives at github.com/storytold.

Sources

Send a msg to start the chat. You can ask the bot anything about me.