I’m running into a problem with the Arducam Pivistation 5 Darksee (B0504) with the Sony IMX678 sensor. Anytime I try to enable HDR through the web interface, the camera just dies. The stream stops completely and nothing I do brings it back — restarting the camera server doesn’t help, I have to do a full reboot of the Pi every single time.
Also, this camera exposes something like 30 video devices in /dev/video*, which seems excessive. qv4l2 doesn’t work at all with any of them. I’m trying to figure out how to actually access camera properties and get HDR working, but the web UI toggle clearly isn’t doing what it’s supposed to. Has anyone gotten HDR working with this sensor on a Pi 5?
Thanks for the detailed report. That definitely doesn’t sound right. Let’s dig into this a bit. Can you share a few more details about your setup?
Which Raspberry Pi model are you running?
What OS and kernel version?
Are you using the latest libcamera and pivariety driver packages?
The ~30 video devices thing is actually somewhat expected with these multi-stream camera modules — each /dev/video node corresponds to a different resolution/format combination that gets enumerated. But qv4l2 not working is odd and might be related to how the pipeline is set up.
I’m testing on both a Raspberry Pi 4 and a Raspberry Pi 5, and the behavior is interesting — the image pipeline is significantly different between the two platforms as you probably know. On the Pi 5 with the pivariety driver, HDR is the main issue. On the Pi 4, the camera behaves a bit differently but I haven’t fully characterized it yet.
The Pi 5 is running the latest Raspberry Pi OS (Bookworm), fully updated. libcamera and the pivariety packages are whatever came from the Arducam setup script — I believe they’re current.
But honestly, my main question is about HDR. The product page mentions ClearHDR since it’s a Starvis 2 sensor (IMX678), and the web UI has an HDR toggle, but enabling it just bricks the camera until reboot. Is this a known issue?
I’ve looked into this and I have some clarification for you — and I want to be straightforward about what’s going on.
Here’s the situation: the Sony IMX678 sensor hardware absolutely does support ClearHDR at the silicon level. That’s not in dispute. However, the current pivariety camera driver for the IMX678 on Raspberry Pi 5 does not implement or expose the sensor’s HDR capability. The driver simply doesn’t have the code paths for HDR mode.
So what you’re seeing is: the web interface sends an HDR command, the driver doesn’t know how to handle it properly, and the pipeline enters a broken state that only a full reboot can recover from. The HDR toggle in the web UI is effectively non-functional with this hardware/driver combination on Pi 5.
Root cause: no HDR support exists in the current IMX678 (pivariety) driver for Raspberry Pi 5. The driver doesn’t expose or implement the sensor’s HDR capability.
Well, that’s disappointing but thanks for the honest answer. So what are my options for HDR then?
I know the IMX708 (Camera Module 3) supports HDR on Raspberry Pi, but that’s not a Starvis 2 sensor and it doesn’t have ClearHDR. My use case specifically needs Starvis 2 with ClearHDR — that’s why I bought the IMX678-based module in the first place.
Here’s what I’m wondering: could I fork one of the standard imxXXX drivers in the kernel, use a different device tree overlay, and handle the raw image conversion in a separate driver — essentially bypassing the Raspberry Pi ISP entirely? I’m comfortable with kernel-level development. I just need to know if the hardware and sensor would allow me to grab raw frames with HDR bracketing and do my own processing in userspace.
I understand the frustration, and I want to acknowledge that the product messaging around HDR has been misleading in this context. We’re working on improving that. The team is also continuing to develop camera performance and extend functionality going forward, but I don’t have a timeline for IMX678 HDR driver support on Pi 5.
Regarding your question about custom driver development — forking existing imx drivers, creating custom device tree overlays, and building a pipeline that bypasses the Pi’s ISP — this falls outside the scope of what we can support through standard product support channels. Our support is focused on ensuring the hardware functions correctly within the officially supported libcamera framework.
That said, at a technical level, the sensor itself is capable of outputting raw frames. Whether you can successfully grab those without going through the ISP pipeline is really a question of how the CSI interface and the UniCam/CFE blocks are configured on the Pi 5. But I can’t provide guidance on building a custom image pipeline — that kind of application-specific engineering isn’t something we cover under standard support.
Just to summarize the key points for anyone else who might run into this:
Sensor-level HDR support ≠ driver-level or framework-level HDR support. The IMX678 has ClearHDR in hardware, but the pivariety driver on Pi 5 has no HDR implementation for this sensor. The HDR toggle in the web UI will crash the pipeline.
The officially supported path is through libcamera. If HDR isn’t exposed through libcamera for your sensor/driver/platform combination, there’s no supported way to enable it currently.
Bypassing the Pi ISP, forking kernel drivers, or using custom device tree overlays is outside the scope of Arducam’s standard product support. That kind of development is application-specific engineering.
For HDR on Raspberry Pi today, the IMX708 (Camera Module 3) is the supported option, though it’s not a Starvis 2 sensor.
I know this isn’t the answer you were hoping for, but I wanted to be clear about where things stand rather than send you down a rabbit hole.