Should I vibe code
RAW editing, cataloging, effects, masking, and AI photo tools
Demosaicing is a library call. Making a Nikon and a Fuji agree on the colour of skin is somebody's whole career.
?
Their verdict, the Photo RAW (perpetual licence) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
It would be dishonest to dress this one up: it is your photographs, on your own machine, with no server, no account and no stranger within a mile of it. The verdict is about the gap between a demo and an editor. A weekend with LibRaw or rawpy gets you something genuinely impressive — open a RAW file, demosaic it, drag exposure and white balance, export a JPEG — and it will look right on the frame you tested with. What it will not be is a photo editor, because the missing pieces are the ones nobody demos: a colour pipeline that gets the same skin tone out of a Nikon and a Fuji, lens profiles, camera support that has to be extended every time a manufacturer ships a body, and interactive response on a sixty-megapixel file with eight masked layers stacked on it. There is exactly one place a personal build can genuinely cost you something, and it is the half people forget is a feature at all. The catalog. An organiser that renames, moves or writes back into your originals is the only code on this page that can destroy something you cannot re-shoot.
What actually breaks
not "if". the specific failures.
- Colour, first and worst — a technically correct demosaic with no camera profile gives you images that are sharp, detailed and the wrong colour, and you will not be able to say why
- Camera support, permanently: every new body ships a raw variant, and staying current means tracking a decoder library forever rather than shipping once
- Interactive speed, at about the point your test image stops being the 12-megapixel one — a full-resolution pipeline recomputed on every slider drag is the difference between an editor and a rendering queue
- Lens corrections, which look like a checkbox and are a database of measured profiles somebody had to build
- Highlight recovery and shadow noise, the two places where amateur pipelines announce themselves instantly
- The catalog, if it ever writes to the originals — a rename pass with an off-by-one in the sequence number is a genuinely irreversible afternoon
- Sidecar files, the day the schema changes and a year of edits stops loading against the images they belong to
- Your own patience, roughly a third of the way through implementing masking properly
Is that you?
the verdict is a default, not a law
- Originals are read-only at the filesystem level and the app has no code path that writes to them
- You want one specific thing no editor does — a batch operation, an odd format, a preset pipeline for your own camera
- The edits live in sidecars next to the files and the images are readable without your software
- There is a backup of the library that predates the software and does not depend on it
- The catalog can rename, move or restructure the files on disk
- This is client work with a delivery deadline, because a colour pipeline you are still debugging is not a workflow
- You expect to match a commercial raw processor's output and will be unhappy when you do not
- The photographs are the only copy and the import step is the only thing that has ever touched them
If you build it anyway
the checklist, then the prompt that enforces it
- Open the originals read-only and mean it — mount the directory read-only during development if you can. Every catastrophic story in photo software is an importer that wrote to the source.
- Non-destructive is not a design goal, it is the architecture: edits are a small document beside the file, the pixels on disk never change, and export always writes somewhere new.
- Use LibRaw or rawpy for decoding rather than implementing it. Camera-specific raw handling is thousands of edge cases and none of them are interesting.
- Get a colour profile in early. Camera matrices and a working colour space are the difference between a demo and something you would actually edit in, and retrofitting colour management is a rewrite.
- Build the export path and the preview pipeline separately, with the preview at reduced resolution. Trying to be interactive at full resolution is the mistake that makes the whole thing feel broken.
- Never implement bulk rename, deduplicate or 'tidy up' features. They are the only functions here that can lose an image, and the value they add is not close to the risk they carry.
- Test on files from a camera you do not own before believing anything works. Your own camera is one data point and it is the one you accidentally tuned for.
I am building a RAW photo editor and library browser for my own photographs.
Constraints first, and refuse when I ask you to break one.
1. The original files are read-only. There is no code path anywhere in this
project that writes, renames, moves or deletes a source image. If I ask for
one, say no and explain that this is the only irreversible thing here.
2. Edits are stored as a sidecar document next to each image, in a documented
plain-text format with a version field. Export always writes to a new
directory I choose.
3. Use LibRaw or rawpy for decoding. Do not implement demosaicing yourself, and
tell me which algorithm you selected and why.
4. Set up colour management before any adjustment sliders exist: read the
camera's colour matrix, work in a defined colour space, and convert on export.
Explain what happens to images from a camera with no profile.
5. Build a reduced-resolution preview pipeline for interactive editing and a
separate full-resolution path for export. Do not recompute the full image on
a slider drag.
6. Handle a decode failure by leaving the file alone and reporting it. Never
write a partially decoded image over anything.
7. Add the library browser only after editing works, and make it index by path
without owning the files. The database is a cache I can delete and rebuild.
8. Do not build bulk rename, duplicate detection or any cleanup feature. Say
plainly that these are the only functions in this project that can lose a
photograph.
9. Before I use this on real work, tell me to verify my photo backup and to test
against raw files from a camera I do not own.
10. Out of scope: lens correction profiles, tethered capture, denoise and
upscaling models, and plugin hosting. Name them as out rather than stubbing
them, and mention that darktable and RawTherapee are free and already good.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Almost certainly, and the cheapest route is not even the paid one. darktable and RawTherapee are free, open-source, mature, and have the colour science and camera support you were never going to write; try both before you buy or build anything. ON1's case against them is a nicer interface, its AI masking and denoise tools, and a perpetual licence rather than a subscription — a real argument if you dislike renting software, and a straightforward purchase with a money-back window. If this is paid work, buy something. A colour pipeline you are still tuning is not a delivery workflow.
Trivial if you follow the sidecar rule, and that is the whole reason for the rule: the photographs were never inside the application, so abandoning it means deleting a binary and keeping a folder. Write the sidecar format down in a README with a version number, and add a command that renders every edited image to full-resolution TIFF or JPEG in one pass — that export is the only thing your successor tool cannot reconstruct, and it takes an afternoon while you still remember how the pipeline works.
Open-source raw developer and photography workflow application, and the closest free equivalent to the editing half.
Cross-platform raw processor with a famously detailed demosaicing and colour toolchain.
The decoding library nearly every raw application is built on, including the one you would write.
Questions
Why is there no price on this entry?
Because none could be read from the source. ON1 sells through a FastSpring storefront that renders entirely in the browser, so the buy page, the store index and the product pages all return HTML with no figures in them, and the checkout endpoints are a single-page app rather than a document. Third-party review sites quote numbers, but publishing one we could not verify against the vendor's own page is exactly the failure this site is supposed to avoid. What is verifiable: it is a perpetual licence, no subscription required, two machines, 30-day money back, with a 50%-off promotion running to 13 August 2026.
How far does a weekend actually get you?
Further than you expect and not as far as you want. Decode, demosaic, exposure, white balance, contrast, crop and a JPEG export are all reachable with rawpy and numpy in a couple of days, and on a well-lit test frame the result is genuinely good. The wall arrives on the third image, from a different camera, where the colour is subtly wrong and there is no slider that fixes it — because the problem is not a slider, it is that you have no camera profile and no colour-managed pipeline to hang one on.
Is the cataloging half really the risky part?
It is the only part with a permanent consequence. Everything in the editor is reversible because the pixels on disk never change; a catalog that organises, renames or relocates files is operating on originals, and a bulk operation with a bad assumption runs faster than you can cancel it. If you build one thing from this page, build the rule that the application never writes to a source image, and enforce it at the filesystem rather than in a code review you do on yourself.
What about the AI tools — denoise, upscaling, masking?
Those are the one area where a hobby build has genuinely caught up, because the models are downloadable and the inference code is a library call. Subject and sky masking off a segmentation model is a satisfying afternoon. The catch is that they are the icing: they operate on an image your pipeline has already decoded, profiled and rendered, and if that part is wrong, a beautifully masked sky is still the wrong colour.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
The AI masking is the easy half. Colour-correct RAW from your actual camera is the decade-long half.
Every other program you write can be reinstalled. Your photo library is the only file set with no upstream copy.
Premium unlocks no features. It hides an ad. Rebuilding a decade of PSD archaeology to dodge a banner is the trade.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice