I’ve been battling with an Arducam B0444 (IMX462 sensor on the Pivariety board) on a Raspberry Pi 4B for astrophotography, and honestly it took days of forum digging just to get it working at all. Even now, the camera is only reliable if I force a restart on every single capture through the INDI driver — which is slow and painful for stacking.
I’m eyeing the UVC3 series (B0496/B0497/B0498) as a potential replacement — more plug-and-play would be a dream. But I need 10-bit RAW data for my astro processing pipeline, and the specs only mention YUY2. Can these UVC3 cameras output 10-bit RAW, or am I out of luck?
Also, if anyone has ideas about my B0444 stability problems, I’m all ears. Right now the camera crashes after the first exposure unless I set force_restart=yes, and that adds several seconds to every frame.
Good question, and unfortunately the answer on the UVC3 front is no — the B0496/B0497/B0498 all have a built-in ISP chip that processes the raw sensor data internally before it hits the USB bus. The raw sensor output is never exposed to the user, so you won’t get 10-bit RAW out of those models.
That said, your B0444 with the Pivariety board absolutely can output RAW data through the rpicam suite, so I think we’re better off troubleshooting what’s going wrong with your current setup rather than switching cameras. The UVC3 series won’t solve your RAW data requirement anyway.
Can you share more about your environment and the exact crash behavior? What does the failure look like — any error messages, logs, or does the camera just go silent after that first exposure?
The weird part: the camera works perfectly fine for basic streaming and image capture when I use libcamera directly. It’s specifically indi_pylibcamera that triggers the problem.
Without force_restart=yes: the first exposure completes, but then the camera crashes hard. Any subsequent capture attempt fails completely — I have to restart the whole INDI server to recover.
With force_restart=yes: the camera re-initializes from scratch for every capture. It works, but it’s painfully slow. For deep-sky work where I’m stacking dozens of frames, those extra seconds per capture really add up.
I’ve poked around for a root cause but honestly I’m stuck.
Thanks for laying all that out — that’s really helpful. I have to be upfront: I haven’t seen another user running this exact combination (RPi 4B + Bullseye 64-bit + Pivariety drivers + indi_pylibcamera), so this looks like an edge case we haven’t had a chance to test against internally.
The fact that force_restart=yes stabilizes things points pretty strongly toward a state management or re-initialization issue between the camera pipeline and the INDI driver. After the first frame is captured and the buffer is released, something isn’t being torn down or reset properly, and the driver ends up in a bad state. The force_restart brute-forces a clean slate each time.
I’ve sent you details about our Arducam Active Users (AAU) program via private message — the engineering team there can dig into these kinds of driver/software interaction issues much deeper than general support can.
One other thing worth mentioning: we’re looking at adding a low-light vision sensor to our Evaluation Kits that would support raw data capture over USB. Might be relevant for your use case down the road, but for now the B0444 is still your best bet for RAW.
Appreciate the honesty. I’ll take a look at the AAU program info you sent.
So just to make sure I’m not missing something obvious — there’s no known fix or configuration tweak for this B0444 + indi_pylibcamera crash? The force_restart workaround is the only option on the table right now?
I was really hoping to avoid the re-initialization delay. For narrowband imaging especially, I’m fighting against limited clear-sky windows and every second of overhead between frames costs me usable data.
Correct — at this stage, force_restart=yes is the only confirmed workaround we have. The root cause hasn’t been pinpointed because this particular combination of hardware, OS, and third-party INDI driver hasn’t crossed our test bench before.
To recap where things stand:
The B0444 hardware itself is fine — it streams and captures normally with stock libcamera. No hardware defect suspected.
The issue is specific to the indi_pylibcamera interaction: after the first exposure completes, the camera/driver state gets corrupted, and only a full re-init clears it.
force_restart=yes prevents the crash, but at the cost of re-initialization overhead on every frame.
The AAU program is honestly your best path to getting engineering-level eyes on this specific driver interaction. If they can identify whether it’s a libcamera pipeline teardown issue or something in the INDI driver’s state handling, there might be a proper fix.
If you do end up finding a more permanent solution through the AAU channels, please do share it back here — there are bound to be other astrophotography folks running into the same wall.