Photography on PHP Boy Scout

Why my photo app won't build for Windows

Sun, 12 Jul 2026 00:00:00 +0000

I was wiring up the release build for krites, the wedding-photo culler I’ve been building for my wife, and I went to add Windows to the list of targets. It felt like the responsible thing. You write software, you ship it for the three big desktops, that’s just tidy. So I added windows to the build config, kicked off a cross-compile from my Linux box, and watched it fall over before it had really started.

Now, the sensible engineer’s instinct at that point is to roll up the sleeves and fix it. Mine was too, for about five minutes… then I read the actual error, thought about who was ever going to run this thing, and did the opposite. I deleted Windows and moved on.

The binary with no C in it

To explain why the build died, I have to back up to a decision that felt clever at the time.

krites does some machine learning. Not for the culling itself, which is deliberately model-free arithmetic, but for the finer judgements: is a subject mid-blink, are they looking at the camera. Those run on ONNX Runtime, Microsoft’s inference engine, which is a big lump of C++ that lives in a shared library.

The usual way to call a C library from Go is CGO. It works, but it comes with a tax: the moment you switch CGO on, building your program means having a C compiler and the right headers for every platform you target. Cross-compiling from one machine to all the others, which is the whole convenience of Go, stops being free. You end up maintaining a little zoo of toolchains just to produce binaries.

So I went the other way. There’s a lovely library called purego that lets you call into a C shared library with CGO switched off entirely. It does the dynamic loading itself, in pure Go, and hands you back function pointers. The ONNX binding krites uses, onnxruntime-purego, is built on it. The upshot is a binary compiled with CGO_ENABLED=0: no C compiler in the build, no headers, cross-compile to anything from my laptop. The provisioner that fetches the runtime library is ordinary Go, net/http and archive/tar, nothing exotic.

Pure Go, no CGO, builds everywhere. You can probably see where this is going…

The trick that doesn’t cross the Channel

Here’s the bit I hadn’t thought hard enough about. How does purego load a shared library without CGO? It calls dlopen.

dlopen is a Unix system call. It’s how a running program reaches out and pulls in a .so or a .dylib at runtime, the thing CGO normally does for you behind the scenes. purego just does it directly. And that’s the whole trick: no C compiler needed, because the loading happens through a system call that’s already sitting there in the OS.

Except it isn’t there on Windows. Windows has its own mechanism for the same job, LoadLibrary, with a completely different shape. So purego’s dlopen and the flags that go with it (RTLD_NOW, RTLD_GLOBAL, if you’ve ever squinted at a Unix man page) simply don’t exist when you compile for Windows. They’re guarded behind a build constraint that reads, in effect, “Linux or macOS or the other BSDs, and nothing else”. Target Windows and those symbols vanish. The binding calls a function that, on that platform, was never compiled in.

My favourite detail is that the binding looks like it supports Windows right up until the moment it can’t. Its library-name helper has a branch for it:

switch runtime.GOOS {
case "darwin":
 return "libonnxruntime.dylib"
case "linux":
 return "libonnxruntime.so"
case "windows":
 return "onnxruntime.dll"
}

It knows the DLL is called onnxruntime.dll. It’s dressed for the party. Then two lines later it goes to actually open the thing with dlopen, the linker looks for a symbol that isn’t there for this target, and the whole build stops. The Windows case is code that can never run, because it can never compile.

So this was never a bug waiting for me to be clever enough to fix. A CGO-free binding buys you a great deal, but it buys it by being Unix. The portability I was so chuffed with was POSIX portability, and Windows was never inside the fence. I’d picked the option that looked like it built everywhere and it still had a border on it.

Knowing where the software actually lives

Which left me with the interesting question, and it wasn’t “how do I make Windows work”. It was “does anyone need it to”.

krites is for Hailey, my wife. She’s a photographer, and she works on a Mac, because that’s what photographers do. The whole plan for the ML side leans into that: the fast path is Apple’s own CoreML running on the M-series chip, the dylib bundled right beside the app. macOS isn’t a platform I tolerate here, it’s the one I’m building for. Linux is the other target, and it earns its place for a different reason, it’s where the CI runs and where a headless batch job would live. Neither of those is Windows. Windows was on the list purely because three feels like a rounder number than two.

So the fix was a diff that removed a line. The release config now lists linux and darwin and stops there, with a comment for the next person (me, in six months, having forgotten all of this) explaining why the obvious third entry isn’t obvious at all.

I could have chased it. There are ways: shim the loader, find a binding that speaks LoadLibrary, turn CGO back on for the Windows build alone and hand-feed it a toolchain. Every one of them is real work in service of a platform my one and only user will never open the app on. That’s effort spent making a number rounder.

A build target isn’t a box you tick to look thorough. It’s a claim about where your software actually lives, and krites lives on a photographer’s Mac. Once I’d said that out loud, the Windows build stopped being a problem to solve. It was a line I got to delete.

You can't reshoot a wedding

Wed, 08 Jul 2026 00:00:00 +0000

A wedding happens once. The first kiss, the confetti, the father of the bride going to pieces halfway through his speech, all of it unrepeatable. If the photographer loses the RAW files from the day, there is no second take. You can apologise, you can offer the money back, but you cannot give anyone the morning again.

So for a tool that sits between a photographer and four thousand irreplaceable files, “don’t damage the originals” is not a feature on a list. It is the entire job. Everything clever krites does, the culling, the sorting, the edits, is worthless the instant it harms a single frame it was handed.

Most software handles this with care. krites handles it by making harm impossible.

Careful isn’t the same as locked out

There is a real difference between a tool that tries not to touch your originals and one that can’t. The first is an intention: a line in the contributing guide, a “we never modify originals” promise, a reviewer remembering to check. Intentions hold right up until the afternoon someone adds a feature in a hurry and forgets. The second is a property of the architecture, and it holds whether or not anyone is paying attention.

krites is built to be the second kind. The guarantee isn’t that I’m careful. It’s that there is no code path that writes to an original, by construction.

Originals go in, and only ever come out as copies

A shoot in krites is just a folder. The imported frames live in originals/, and they are treated as read-only inputs, never written after import. Every decision krites makes lands in a hidden .krites/ sidecar tree beside them. The only place new pixels are ever produced is a separate export/ directory, written when you explicitly export. (The layout of all this is the shoot workspace, spec 0001 §3.)

The code says the same thing the design does. The package that owns the workspace opens with it:

// Package shoot is the non-destructive shoot workspace: a directory of original
// frames plus a .krites sidecar tree holding the manifest and the culling
// verdicts. Originals are inputs, never written after ingest.

And the only function that opens an original opens it one way:

// OpenFrame opens an original frame read-only by its manifest-relative path.

There is no open-an-original-for-writing function anywhere, because nothing legitimately needs one (shoot.go, OpenFrame).

A verdict is a record, not a scalpel

This works because of one decision that runs through everything: a verdict, a crop, a straighten, a colour grade, is a record, not a change to a pixel. Keep, maybe, reject is a line in verdicts.yaml. An edit is an instruction in edits/. Nothing has been done to the photo; krites has just written down what it would do.

The only command in the whole tool that produces output pixels is export, and it renders those instructions into the export/ directory, never back over an original. Even the function that copies a chosen frame out says so in as many words:

// CopyToExport copies an original frame verbatim into the shoot's export/
// directory. It is the only writer outside .krites and never touches the
// originals.

That’s the load-bearing contract the spec calls out by name (R-ND-1 and R-ND-2): originals are never modified, and the only thing that writes new pixels is export (the non-destructive guarantee, CopyToExport).

Two things fall out of it for free. Because every decision is a record, undo is total: a “reset” returns a frame to exactly its just-imported state, because nothing was ever actually changed (R-ND-3). And because the analysis scores and the browsing previews are only caches, you can delete the whole .krites/analysis/ and .krites/previews/ and rebuild them with no loss of a single decision (R-ND-4). The durable things are the verdicts and the edits; everything else is disposable.

Even “delete” doesn’t delete

The most frightening verb in any library tool is delete. You hover over the button… you think about what’s behind it.

In krites, removing a shoot forgets it. It drops the shoot from the studio’s list of folders it knows about, and it does not touch a single file on disk:

// Remove forgets a shoot from the library; it never touches the shoot's files.

The HTTP endpoint behind the studio’s delete button is held to the same rule: it forgets the shoot, it never deletes files (Remove). The scariest control in the interface has been defanged. The worst it can do is make krites stop paying attention to a folder that is still, untouched, exactly where you left it.

Where the rule actually lives

The studio’s contract states it outright: non-destructive by construction, no endpoint mutates an original. That phrase is the whole idea in three words. The promise isn’t kept by me being disciplined every time I add a feature. It’s kept by how the code is built: originals open read-only, exactly one writer lives outside the sidecar tree and it writes to export/, and there is no other door.

When the cost of a mistake is total and unrecoverable, you don’t build a tool that avoids the mistake. You build one where the mistake can’t be made.

The motto on this blog is to leave the codebase better than you found it. Here the rule is narrower and stricter, and a wedding depends on it: leave the originals exactly as you found them. Every byte, every frame, every time.

The folder it can’t write to

Hailey is never going to read a requirement labelled R-API-2. She doesn’t need to. She needs to know that the tool sorting four thousand photos of someone’s most important day cannot, under any circumstances, be the thing that loses them. So I made sure it can’t. There’s one folder krites is simply never allowed to write to. The rest of the tool I’ll argue about all day; not that one.

There's no AI in my photo culler

Wed, 01 Jul 2026 00:00:00 +0000

Before a wedding photographer can edit a single frame, there’s the cull: sitting down with three or four thousand photos from the day and deciding which are even worth keeping. The blurry ones, the ones where the flash fired into a mirror, the same moment shot eight times in a burst where only one frame is sharp. It’s mechanical, it’s exhausting, and it’s the first job krites does for Hailey.

Every culling tool I looked at before building it leads with the same word. AI. AI culling, AI selects, trained on millions of weddings. So when I sat down to write krites’ first pass, I assumed I’d be wiring up a model too. For the part that does the most work, it turns out, I didn’t need one.

The shipped culler doesn’t load a single weight. It’s arithmetic, the sort a calculator could do if you were patient enough, and that’s a deliberate choice rather than a corner I cut. Here’s what’s actually under it.

Blur is the variance of a Laplacian

The first question for any frame is whether it’s in focus. You can answer it without knowing anything about what’s in the photo.

A Laplacian is an edge detector. Run it over an image and it lights up wherever the brightness changes sharply, the crisp boundary between a dark suit and a white shirt, the line of an eyelash. A photo in focus is full of those sharp transitions; a soft or motion-blurred one has smeared them all into gentle gradients. So if you measure how much the edge response varies across the frame, a sharp photo gives you a big spread of values and a blurry one gives you a flat, lifeless number. That single number is the focus score.

In krites it’s a 3×3 kernel over the frame’s luma (the brightness channel, Rec. 601 weights), and the score is the variance of the response:

lap := int(luma[(y-1)*w+x]) + int(luma[(y+1)*w+x]) +
 int(luma[y*w+x-1]) + int(luma[y*w+x+1]) - lapCenter*c

Sum the responses, sum their squares, and the variance falls out as sumSq/n - mean*mean. No training data, no inference, and the same pixels always give the same answer. (quality.go.)

Exposure is a histogram

The second question is whether the exposure is salvageable. If a third of the frame is pure white, the highlights are blown and there’s no detail to bring back; if it’s mostly pure black, the shadows are crushed the same way.

That’s just counting. Walk the luma plane once, tally how many pixels sit at or above a near-white threshold and how many at or below a near-black one, divide by the total, and you’ve got two fractions: the blown-highlight proportion and the crushed-shadow proportion. A photographer cares about those two numbers directly, and a for loop produces them (quality.go).

Two photos are the same when sixty-four bits agree

Then there are the bursts. A photographer holds the shutter through the first kiss and gets twelve nearly-identical frames; you want the sharpest one and the rest out of the way. To do that the tool has to know which frames are “the same shot”, and again you don’t need to understand the photo to tell.

The trick is a perceptual hash, a difference hash to be exact. Shrink the image right down to a nine-by-eight grey thumbnail, then for each row note simply whether each cell is brighter than the one to its right. That’s sixty-four yes/no comparisons, packed into a sixty-four-bit number, a fingerprint of the picture’s broad light-and-dark structure that survives a resize, a small reframe or a touch of noise:

if grey[y*hashW+x] > grey[y*hashW+x+1] {
 h |= Hash(1) << bit
}

Two fingerprints are compared by counting the bits that differ between them, the Hamming distance, which on a 64-bit integer is one CPU instruction (bits.OnesCount64). A small distance means the frames look alike. krites only clusters consecutive frames within that distance, so a run of similar shots merges into a burst but two unrelated photos that happen to rhyme don’t (dedup.go).

Best-of-burst is then the dullest line of code in the project: keep the sharpest frame in the cluster, demote the others from keep to maybe, and write down why.

fv.Reasons = append(fv.Reasons, "near-duplicate of "+bestFrame+" (kept the sharper frame)")

Signals in, a verdict out

None of those measurements decide anything on their own. A focus score of 50 is rejectable on one shoot and fine on another, because the numbers scale with resolution and content. So the signals feed a profile, a small set of thresholds, and the profile turns them into a ruling: below the hard focus gate it’s a reject, below a softer floor it’s a maybe, blown past the exposure gates it’s a reject, otherwise it’s a keep. Every verdict carries its reasons in plain words, “out of focus (sharpness 32 below 50)”, because krites proposes and the human disposes (cull.go).

The seed thresholds for a wedding are just a starting point, written to config on krites init and tuned from there:

seedMinSharpness = 50 // below this: rejected as out of focus
seedSoftSharpness = 150 // below this (but >= min): demoted to maybe
seedMaxHighlights = 0.10
seedMaxShadows = 0.30
seedDedupDistance = 8

The thresholds are the whole point of keeping them visible. “Suitable for a wedding album” is Hailey’s definition, not mine and not a model’s, and a number in a config file is something she can move (profile.go).

Where the models do belong

I’m not claiming AI has no place in this. Some of what a wedding photographer culls on genuinely needs a model: is this person mid-blink, is anyone actually looking at the camera, is the composition any good. Those are coming, and they’ll be model-backed when they do. The deliberate bit is that they sit outside this deterministic core, behind an interface, opt-in. The maths that does the heavy lifting of the first pass never imports a model.

That separation buys three things you lose the moment a neural net touches the hot path. It’s reproducible: the same frames in the same order always cull the same way, so a verdict is debuggable and a regression is catchable. It’s quick enough to run over four thousand frames on a laptop with no GPU. And it stays honest about what it knows, because a threshold you can read is a threshold you can argue with, which a confidence score from a black box never quite is.

“AI culling” makes for a better headline. But blur really is just a number, a duplicate really is just sixty-four bits, and the grim, mechanical first pass that stands between a photographer and their best photos comes down to arithmetic.

I built my wife a judge

Mon, 22 Jun 2026 00:00:00 +0000

The morning after Hailey shot a wedding, we were both wrecked, lying in bed and not really moving, and she said she might just pay for Aftershoot to get through the cull. And my ears pricked up.

She’d been on her feet for the best part of fourteen hours the day before. She had four thousand photos waiting for her. And I, lying there next to her, realised that for the first time the thing I do in my spare time, the obsession that mostly just pays my half of the bills, might actually be of some use to her.

Four thousand photos and the weeks that follow

A bit of background. My wife is a photographer. Not full-time yet, but that’s the plan, and she’s been chipping away at it around life and the bills ever since she set up Echos Photography a couple of years ago. Her real love is landscape and animals, the patient stuff, but every so often she’ll take on a wedding or some portraits, and last weekend she was the photographer for a family friend’s big day. A lovely affair. She shot it; I flew the drone for a bit of aerial photography and video, which mostly means I got to stand in a field feeling useful while she did the actual work.

Then it ends, and the real job starts. Four thousand frames, and before a single one gets edited somebody has to sit and look at every one and decide which are even worth keeping. The blinks, the soft ones, the same moment fired off eight times in a burst where only one frame is sharp. Done by hand, in Lightroom, one at a time, that can take her weeks. Months, sometimes, depending on what else life is throwing at her. So when she said she’d pay a subscription to make the first pass go away, I understood completely. It’s a genuinely grim job.

I just thought I could do better… for her, specifically.

Why my ears pricked up

I’ve been building developer tools for a while now. go-tool-base has reached the point where it’s actually pleasant to build things on, and the work I’d been doing on keryx, a little studio you drive from a browser rather than a command line, had shown me the shape of something a non-developer could use without ever touching a terminal. The pieces were sitting there… they just needed pointing at a different problem.

So I built her a judge. That’s what the name means, as it happens. krites is Ancient Greek for “the judge”, and that’s the whole product in one word: the thing that looks at every frame and rules on it, keep, maybe, reject, with its reasons, so the human doesn’t have to do the first exhausting pass by hand. It judges; she still decides. It proposes, she disposes. The tool never gets the last word, and it was never meant to.

A tool that’s only trying to please one person

Here’s the thing an off-the-shelf product can never quite be: krites is opinionated entirely in Hailey’s favour. It’s built around her workflow, her kit, her idea of what makes a frame worth keeping, and it’s designed so that she can use it with no setup and no technical knowledge whatsoever. The day it asks her to edit a config file is the day I’ve failed.

I’ve also kept it deliberately dim. There’s very little machine learning in it, and that’s a choice rather than a limitation. Most of the first pass, deciding whether a photo is in focus or hopelessly blown out, whether it’s the eighth near-identical frame in a burst, turns out to be arithmetic, and arithmetic is simple, fast and predictable in a way a model never quite is. I’ll reach for ML where there’s genuinely no other way (telling whether someone’s mid-blink is the obvious one), and when I do it’ll lean on the Apple hardware she already owns, with a deliberate gap left so it can grow onto other machines later. But the rule is: no cleverness she doesn’t need.

And it all runs on her own machine, on purpose. No subscription, which matters when the photography isn’t paying for itself yet. No reliance on a connection, which matters because we’re hoping to spend a good chunk of the near future on the road (there’s a whole vanlife plan brewing, with a work-in-progress demo site slowly coming together), and a campsite in the middle of nowhere is exactly where you want to be culling a backlog and exactly where you won’t have signal. And nothing leaves the laptop, which matters most of all, because these are other people’s weddings. Their photos shouldn’t have to go and live on somebody’s cloud to be useful to the woman they hired.

Why not just pay for the thing that exists

Aftershoot is good. Genuinely good. The easy version of this post is the one where I sneer at the incumbent, and I won’t: they’ve built something clever, and plenty of photographers are well served by it.

But it’s a product, and a product is a compromise by definition. It’s built for the average of everyone, and it can only ever evolve in the directions a company decides are profitable. Hailey isn’t the average of everyone. Something I build is hers, and it can grow in any direction she can imagine, including the unprofitable, niche, only-makes-sense-for-one-photographer directions that no company would ever green-light. That’s not really a technical argument. It’s closer to pride. I’d rather build my wife the tool than rent her someone else’s.

Early days, and the people who made it possible

A word on where this actually is, though. What’s shipped today is the cull, the first pass I’ve described. The straightening, the cropping, the colour work, the little retouches that eat her evenings, the part where it learns her taste over time, that’s all roadmap, and I’ll write about each piece as it lands. krites is at the very start of its life.

None of it would exist at all without three things, and only one of them is mine. go-tool-base finally being solid enough to stand on. Being able to build, with a lot of AI assistance, far faster than I ever could have managed alone, fast enough that “I could probably build that” became “I have built that” inside a weekend. And Hailey, whose infinite patience and gracious kindness in indulging my passions is the only reason any of my obsessions ever get the room to become something.

Which is the part I keep coming back to. I’ve written before about the cost of the compulsion to build, the evenings it takes and the people it takes them from. krites is the same compulsion, for once, pointed the other way. The thing that usually pulls me away from her, aimed squarely at giving her her evenings back. I don’t think I’ve enjoyed building anything more.

She still gets the final say on every photo. Obviously. She’s the judge that matters. I just built her a faster one to argue with.