[Feature Request] Add OS04D10 sensor driver support for SSC377D (Infinity6C)

[byfaruk]

Feature Request: OS04D10 Sensor Driver Support

Summary

Please add driver support for the OmniVision OS04D10 sensor on the SigmaStar SSC377D (Infinity6C) platform.

Current situation

• The sensor_os04d10_mipi.ko driver is not present in the current OpenIPC build for SSC377D / Infinity6C.
• Cameras using the OS04D10 sensor with SSC377D SoC cannot be flashed with stock OpenIPC firmware without a working sensor driver.

Hardware details

• SoC: SigmaStar SSC377D (Infinity6C family)
• Sensor: OmniVision OS04D10 (4MP, MIPI CSI-2)
• Interface: MIPI 2-lane, 10-bit
• Bayer pattern: BGGR
• Typical resolution: 2560x1440 @ 30fps

Why this matters

The OS04D10 + SSC377D combination is widely used in low-cost 4MP IP cameras currently entering the market. Lack of driver support forces users to stay on stock (often insecure) vendor firmware.

What we need

1. sensor_os04d10_mipi.ko kernel module built against the Infinity6C BSP
2. Matching IQ/tuning bin file (os04d10.bin)
3. Sensor entry in majestic/ISP config

Additional info

• Stock vendor firmware works correctly with this sensor (colors, IR-cut, AWB all functional), confirming the hardware is standard.
• I am able to test builds on real hardware and provide logs / dumps if a developer picks this up.

Thank you!

[flyrouter]

Good afternoon
Thank you for your interest in our project
At the moment, only a similar driver is publicly available in our repositories.
https://github.com/OpenIPC/sensors/blob/master/sigmastar/infinity6c/sensor_os04a10_mipi.c
If you want to financially invest in research through the OpenCollective platform or in another way, you can discuss this in a PM with the key developers of our project.

[byfaruk]

Thank you for the quick response and for pointing me to the existing os04a10_mipi driver as a reference.
I'm willing to financially support this work. Could you please let me know which developer I should contact via PM to discuss the scope, timeline, and payment details? I'd like to move forward as soon as possible so we can get proper OS04D10 support for the SSC377D / Infinity6C platform.
As mentioned, I can also provide hardware for testing, logs, and register dumps during development.
Looking forward to your reply.

[byfaruk]

https://github.com/OpenIPC/sensors/blob/master/sigmastar/infinity6c/sensor_os04a10_mipi.c @flyrouter
Problem: OpenIPC OS04D10 image is hazy/grainy vs. sharp on UniView stock firmware. Root cause: /etc/sensors/os04d10.bin is actually the OS04A10 IQ file (wrong tuning). Majestic expects ISP version 4 but file is version 2 → soft ISP bypass → no proper denoise/sharpness curve. No real OS04D10 IQ bin exists in OpenIPC repo. Workaround so far: testing other sensors' IQ bins (imx335, sc401ai) as substitutes — partial improvement only.

sahacam-openipc.tar.gz

[flyrouter]

You can turn on the IQ Server and use the utility to configure exactly what you need:

https://openipc.org/utilities
SigmaStarCam IQTool v2.01.114

[ZigFisher]

Thank you, we will review your archive next week.

[byfaruk]

@ZigFisher Image is not sharp and has strong light flare/vertical streaks. Issue is not dome/lens contamination — likely caused by sensor driver mismatch or ISP tuning problem (too high AGC and wrong DWDR settings). OpenIPC may be using wrong sensor driver for OS04D10, causing incorrect register configuration and poor image quality. Could you prepare a sensor-equipped device for me based on the information I've shared?

[byfaruk]

I've significantly improved the colors and appearance, but it's still not perfectly clear, and there are some light glares. @flyrouter @ZigFisher

install.sh

[byfaruk]

I'm running OS04D10 (4MP, 2560x1440) on a Sigmastar SSC377D SoC (infinity6c family) under OpenIPC. Indoor scenes with bright LED ceiling lights produce vertical 4-pointed star streaks that no amount of ISP-side post-processing can fully eliminate.

I'd like to request implementation of an automatic highlight detection + suppression feature in either the sensor driver or ISP pipeline.

What this feature does (in OmniVision/Sony reference designs)

1. Per-frame highlight detection
   A statistics block scans the previous frame's luma histogram and flags pixels above a threshold (e.g. Y > 240). When the saturated-pixel ratio exceeds a configurable target (e.g. 1%), the system enters "highlight protection mode."

2. Automatic exposure clamp (sensor-side)

Reduce sensor analog gain to minimum
Force shutter to the shortest line-time the sensor supports (sub-millisecond range)
Optionally engage built-in PWM/dimming if the sensor exposes it
3. ISP-side rolloff (highlight knee)

Apply a programmable tone curve that compresses Y > 200 region (knee point + slope)
Engage WDR/HDR curve in single-frame mode (LTM) if enabled
Reduce edge sharpening (OverShootGain, UnderShootGain) only in saturated regions to prevent ringing artifacts that look like spikes
4. Localized chroma desaturation

For pixels where Y > threshold, drop saturation (S in HSV) to ~0.4-0.6
This kills the magenta/green halo that LED clipping produces
5. Hysteresis / smoothing

Don't toggle the protection mode every frame; require N consecutive frames above/below threshold before switching (prevents flicker)
Reference implementations
This is sometimes called:

HLC (Highlight Compensation) - Hikvision marketing term, implemented in their sensor module/ISP combos
Anti-Bloom / Bloom Reduction - some OmniVision sensors expose a bloom_thresh register
Dynamic Range Compression (DRC) - Sony/OnSemi naming
Highlight Priority AE - in CMOS auto-exposure literature
Why it matters for OpenIPC users
Stock vendor firmware (UNV in my case) does this automatically and produces clean LED-rich indoor scenes
After flashing OpenIPC + stock OS04D10 driver, LEDs clip and produce 4-pointed star streaks (lens diffraction amplified by sensor saturation)
Manual ISP tuning (PFC, WDR curve, HSV saturation cap, sharpening kill) only gets ~85% reduction
The remaining streak is sensor doing nothing to prevent saturation in the first place
What I tried in the existing driver
In sensor_os04d10_mipi.c (sigmastar/infinity6c) I see:

Preview_MCLK_SPEED CUS_CMU_CLK_24MHZ
Standard register init via 0xFD page-select
GAIN_MAX register (tried lowering, broke I2C init)
No exposed hooks for highlight feedback or auto AE compression
The ISP IQ binary has PFC (cls=0x10 iid=0x1b), WDR (0x16), WDRCurveFull (0x35), HSV (0x18) sections — but these are static curves, not adaptive. They apply uniformly regardless of scene.

Feature request
Could the driver / ISP wrapper expose:

A statistics callback per frame: mi_isp_get_luma_histogram(dev_id, &histogram)
A dynamic AE override: mi_isp_set_max_exposure(dev_id, max_us, max_gain) callable from a userspace daemon
An ISP scratch curve apply: mi_isp_apply_dynamic_curve(dev_id, curve_table[33]) for tone compression
With those three primitives a userspace daemon (or even a kernel timer) could implement the full HLC loop in ~200 lines of C.

Alternatively, port the existing CUS3A (Custom AE/AWB/AF) callback API that the SDK already exposes — the hooks are there in MI_ISP_CUS3A_Enable, just nothing uses them for highlight compression in the sensor driver.

Hardware
SoC: Sigmastar SSC377D (Maruko, infinity6c)
Sensor: OmniVision OS04D10 (4MP, MIPI 2-lane, no DCG)
Camera: UNV IPC2124LB-ASF28K-A
OpenIPC: master+34467ec, kernel 5.10.61 PREEMPT (Apr 30 2026 build)
mi.ko: md5 353a5225a0bf77179df7c834e763bb3d
sensor_os04d10_mipi.ko: md5 744da956f536a7998d6a81bcdd3c8326
Related
This is an OS04D10 vs OS04A10 difference too: OS04A10 has user-toggleable DCG, OS04D10 only has SCG, which makes saturation harder to avoid without an active highlight loop.

Happy to test patches.

[byfaruk]

@ZigFisher Weeks ago, an update was needed to help us get a clearer image. Could you please update the posts? I've fixed the light reflection issue, but the image is still not clear.
@flyrouter

[byfaruk]

The OpenIPC port of the Uniview IPC324LB-ASF28K-A (OS04D10 sensor) achieves roughly 70% image parity with the stock firmware. Core sensor parameters match (resolution, lanes, MCLK, IR-cut), but the ISP stack is fundamentally different. The stock UNV firmware uses a scene-aware ISP pipeline with 16-step ISO tables, multi-preset AWB (3000K–6000K), DHLC bloom suppression, and chroma noise recovery. OpenIPC/Majestic uses a single flat sensor binary with no equivalent tuning depth. The result: acceptable daytime image but no LED halo suppression, weaker low-light chroma NR, and a slight green cast from single-mode AWB.

default_pic_OS04D10.xml

isp_api.xml
@ZigFisher @flyrouter