What changed this year
I started these posts in 2018 to document changes in apps, backups, exports, and culling. This year I changed both my editor and my backup service.
The difference this year is that the editor is no longer the whole question. The editor matters, but the more important question now is whether the archive stays portable, backed up, and publishable without being trapped inside one company’s app, cloud library, or subscription plan.
Photomator Was Close
I still love Photomator. The desktop/mobile workflow is genuinely good. Moving between the Mac, iPad, and Apple Photos library with so little friction solved a real problem. The auto-masking is fast: it makes local adjustments quick.
I also still like the idea of Photomator, especially after Apple acquired Pixelmator. The first photo editor I used seriously was Aperture, so I still hope Apple will make something that suits me as well. That has not happened yet.
The problem was not that Photomator became bad. It did not. It is a good app. The problem was that the results stopped feeling strong enough to make it the center of the whole workflow.
The Capture One Detour
After that, I tried Capture One. I signed up for the trial, liked a lot of what I saw, then realized it was not the right fit about a week into a yearly subscription I had already paid for.
Some of this is taste, some of it is irritation, and some of it is the ongoing daydream that if I buy the Hasselblad X2D II 100C, my photography will somehow improve. Buying a camera will not settle which editor I prefer.
Capture One made one useful thing clear: I had been over-weighting file syncing as a requirement. If an editor did not have a way to sync files, I dismissed it. Once that rule loosened, other options became possible.
Reprocessing the Catalog, Again
There is a ridiculous pleasure in re-processing the catalog of selects every time the software changes.
It is also a pain in the ass.
The 2025 Photomator move already forced this realization. Losing old Lightroom edits sounded awful until I treated it as a chance to revisit the images with my current eye. Taste changes. What I liked ten years ago is not always what I like now.
That part is worthwhile. Re-editing old work is a way to see your taste changing in public. The practical problem is different: when edits live inside app-specific systems, switching costs become archive costs. I do not want the archive to depend on my memory of which app contained the latest edit.
Why DxO PhotoLab 9 Stuck
With the syncing requirement relaxed, I tried DxO PhotoLab 9.
Fast-forward to now: I am using it exclusively for photo processing.
The AI masking is not as fast as Photomator’s, but it works. I need it to help me dodge and burn without making the adjustment difficult.
The part that stuck is the RAW processing. DxO’s camera and lens profiles, the DxO Modules, give me results I like. I spend less effort correcting noise, lens distortion, color, and detail.
The multi-export workflow helps too. One processed file can move out in the sizes and formats I need without repeated manual exports. DxO fits because it makes the working file look good and lets me get finished images out cleanly.
Keeping edits beside the RAW files
The sidecar files matter as much as the editing tools.
DxO stores edits in .dop sidecar files beside the original RAW files. They are still DxO-specific. I am not pretending some other editor can open a .dop file and magically recreate the edit.
The point is that the instructions live next to the source file.
That changes how much I trust the archive. With Photomator, edits lived in a specific iCloud folder, and in my experience that was not always as reliable as I wanted. The archive felt too dependent on storage behavior I could not easily inspect.
With DxO, the RAW and the edit sidecar travel together. If I move the folder, the edit instructions move with it. If I back up the RAW, I back up the .dop file beside it. If I restore a folder later, I am restoring both the original file and its edit instructions.
Keeping the files together makes the archive easier to understand and reduces the chance that I’ll have to recreate a lost edit.
Cold Storage Got Simpler
The backup side changed too.
I moved the RAW archive from Google Cloud to S3 Glacier Deep Archive. Right now, it is costing a little over $5/month for almost 6TB of backups.
That is absurdly cheap, with the obvious caveat that Glacier Deep Archive is not a fast working drive. I am not using it as an active photo server. It is cold storage. The point is that if the local files are lost, the files that should survive have a durable offsite copy.
The Archive Has a Public Home Again
I used Claude Code to build a custom version of Sam Becker’s EXIF Photo Blog and now have it running at photo.banast.as.
Claude Code is not the point here. It was useful, but the important part is that I have a public archive I control again. The selected images do not only live inside Instagram, Apple Photos, Lightroom, DxO, or an old archive system I stopped maintaining.
A public photo archive gives the finished work a stable address outside an editor or social feed. It connects back to why I keep building these little personal systems: I like having my own infrastructure for the things I care about.
Current Snapshot
So this is the 2026 version.
Photomator was close. Capture One was an expensive detour. DxO PhotoLab 9 is the editor that stuck. The RAW files now stay with their .dop sidecars. The cold archive sits in S3 Glacier Deep Archive. The selected images have a public home at photo.banast.as.
This records what works for me now, including the compromises. My preferences will probably change again.
The useful shift is that the workflow is finally less about chasing the perfect app and more about keeping the archive understandable and recoverable: RAW files, sidecars, cold storage, and a place to publish.