Built-in camera scanning for NegPy — narrowband-RGB + white-light capture

[light-sntchr]

Hi Marcin, and everyone 👋

First: thank you for NegPy. I scan film at home and it's become the heart of my workflow, the RGB Scan trichromatic merge especially is something I couldn't find anywhere else.

I'd like to float an idea before writing any code at you: a camera-scanning workflow built directly into NegPy, so you can capture a negative with a camera + an RGB light source and go straight to a finished positive — capture, merge, invert, finish — all in one app.

Full transparency up front: I'm not a professional developer. I "vibe-coded" the whole thing with Claude, as someone who just wanted this to exist. I'm saying that on purpose, because I think it's actually a point in its favour here — more on that below.

Why this fits NegPy specifically

NegPy already has the clever half. In #288, @rohanpandula proposed the RGB separation mode and you built the sub-pixel-aligned RGB Scan merge (features/rgbscan) from his sample files. What NegPy still doesn't have is the capture half — so today you shoot the three exposures in some other app and bring the folder in afterwards.

This proposal closes that gap: a capture layer that produces exactly the R/G/B triplets your merge already expects, plus a normal white-light mode, without touching the merge or inversion pipeline at all.

Narrowband RGB is worth the three shots, incidentally: a single broadband exposure lets the dye layers contaminate each other, and the green Bayer filter — the broadest — picks up leakage from the red and blue light at once. One LED at a time removes that crosstalk by construction, and each channel gets the sensor's full dynamic range instead of sharing it (the approach in the Flückiger et al. film-scanning research).

What it does

• Normal camera scanning — capture a negative (or slide, or B&W) as a single frame with any supported camera, imported straight into NegPy. This is the default and needs no special light.
• Narrowband-RGB scanning (the opt-in extra) — when jackw01's open-source Scanlight is connected, the tab switches on a mode that flashes R → G → B while the camera captures each exposure, then hands the three RAWs to your existing RGB Scan merge + invert. (The tab auto-switches between the two modes depending on whether the Scanlight is present.)
• Per-channel ETTR auto-calibration — you mark a spot on the clear film base; it meters it and solves the LED levels + shutter so every channel is exposed to the top of the sensor's range, with a clip-guard that protects the exact highlight that becomes your black point after inversion.
• Film-stock presets — save/recall the R/G/B levels + shutter per stock.
• Live view with focus aids — streams the camera into the app, click-to-place the hardware focus magnifier, live ISO/shutter/WB controls.
• Painless connection — USB is auto-detected; Wi-Fi via a small login dialog.
• Roll-friendly & quick — frames auto-number into per-roll subfolders and auto-import + merge after each shot; capture runs inside the live-view session so there's no per-frame reconnect (~7 s per RGB triplet on my a7C II over USB, which is the camera SDK's practical floor).

What you'd need — and what you wouldn't

• A Sony camera. It's Sony-only for now, purely because that's the gear I own — I can only build and test against cameras I can actually hold. The design is a small per-camera "helper" behind a simple text protocol, so other brands could be added later by someone with that hardware; the rest of NegPy wouldn't change. (Tested on a Sony a7C II and a ZV-E1.)
• Sony's Camera Remote SDK — a free download from Sony, but its licence means it can't be redistributed, so a user installs it once themselves. NegPy runs perfectly fine without it: if the SDK/helper isn't present, the Camera Scanning tab just shows a one-line setup hint, and every other part of NegPy is completely unaffected. Nothing Sony ever ships inside NegPy.
• For RGB scans only: the Scanlight (jackw01's open-source RGB light). Without it you can still scan normally — you just don't get the narrowband triplet mode. The light itself is driven straight from Python over pyserial; no new heavy dependencies.

Under the hood — kept deliberately clean

Because it was AI-assisted, I worked hard to keep it aligned with how NegPy is actually built, rather than bolting on a mess:

• Your merge/inversion is untouched. The capture layer only feeds features/rgbscan. The whole feature touches just three of your existing source files (controller.py, right_panel.py, pyproject.toml) — plus an architecture section in CLAUDE.md and a new docs/CAMERA_SCANNING.md. Everything else is new, self-contained modules. (pyserial is the one new dependency, and I'm happy to make it an optional extra if you'd rather.)
• It stays GPL-clean. This is the part I was most careful about. Sony's SDK is proprietary, so it is never bundled, committed, or linked into NegPy. The only thing that links it is the separate MIT-licensed sony-capture helper, which runs as its own process and talks to NegPy over a plain stdin/stdout line protocol. No proprietary code ever enters the NegPy binary, and every user supplies their own copy of the SDK.
• It comes batteries-included. It ships with its own test suite; the full project suite passes (1341 tests), it follows your feature pattern and is make all-clean, and it's rebased onto the official 0.35.0.
• Proven end-to-end on real hardware (Sony a7C II): live view, focus, calibration, triplet scan → merged + inverted → good-looking images.
• I've only been able to test on macOS (that's all the hardware + SDK I have), but the Python layer is portable and the C++ helper is written to compile on Windows, macOS and Linux — so it should run on all three, with macOS the one I can vouch for.

Testing and maintenance

In #288 you mentioned you don't have a scanning setup like this, and I realise that's a fair reason to hesitate over hardware code you can't run yourself. So, concretely:

• CI needs no hardware. The camera and the light sit behind small protocols and every capture test runs against fakes (the raw-decode and clip checks are injectable too). The suite passes on a machine with nothing plugged in.
• Users without the hardware see no change. No helper → a one-line hint. No Scanlight → the narrowband mode simply isn't offered.
• I'm happy to own that corner — keep testing against my rig, fix what breaks, and take the issues that come with it.

And practically: I can send you sample R/G/B triplets and record a short screen capture of a full calibrate-and-scan, so you can see the whole loop working without owning a rig — the same way the merge got built.

Credit — and a question for @rohanpandula

A lot of the capture foundation comes from @rohanpandula's TriRGB project (https://github.com/rohanpandula/TriRGB, MIT): in particular the sony-capture helper and the R/G/B sequencing + exposure-calibration approach, which I built on and adapted to fit NegPy. My additions to the helper (host-side capture inside a live-view session, per-camera focus-magnifier ratios, multi-camera support, a cross-platform build) live on a branch of a fork.

@rohanpandula — I hope that's OK with you! I'd love your blessing to propose this here, and I'm happy to credit it however you'd prefer, or to send the helper changes back your way if you want them. Thanks too to jackw01 for the open-source Scanlight hardware.

Have a look

It's all pushed and ready to browse — no pull request, nothing landing in your inbox, just code you can look at whenever you feel like it:

• The feature, one commit on top of 0.35.0: https://github.com/light-sntchr/NegPy/tree/camera-scanning
• The exact diff against your main: main...light-sntchr:NegPy:camera-scanning
• Setup + troubleshooting docs: docs/CAMERA_SCANNING.md
• The sony-capture helper: https://github.com/light-sntchr/TriRGB/tree/sony-capture-negpy

The ask

Is a built-in camera-scanning workflow something you'd want in official NegPy?

If it is, I'll happily open a proper PR, record a demo, or reshape it to fit your plans — including keeping it optional/opt-in if you'd rather the core stay lean. If it's out of scope for where you're taking NegPy, that's completely fair too — either way, thank you for building such a clean codebase that a non-dev could extend it this far.

Thanks for reading! 🙏

[rohanpandula]

Hell yes! this is awesome, if it ends up getting merged into negpy, ill archive my own version as this is superior in every way! Thanks for making/sharing this @light-sntchr

[light-sntchr]

Ha, thank you! :) Don't archive anything though, sony-capture is your program. I just taught it to shoot inside a live-view session and to stop assuming one camera model.

If you ever get a spare evening, does it actually run on your rig? I've only tested an a7C II and a ZV-E1, so yours would be the first body I've never touched.

[marcinz606]

amazing! I actually wanted to look into it sometime in the future but you beat me to it!

[marcinz606]

Please open a PR once you are happy with it, hopefully we can extend it to support more camera brands with some crowdsourcing in the future

[marcinz606]

After some googling i think that maybe using
http://www.gphoto.org/proj/libgphoto2/
https://github.com/jim-easterbrook/python-gphoto2

would allow for FOSS camera support across many manufacturers