Skip to content

Whitepaper · ISP & sensors · Drivers, modes and image quality

The sensor your datasheet promised, at the frame rate it promised.

A camera is a sensor, an image pipeline and a driver that must agree with both. We port sensors to new silicon, recover the modes the vendor driver never exposed, and tune the pipeline so the picture is measured rather than guessed.

Send us the sensor and the board How an engagement works

21 fps up from a broken 6 on the same silicon — a 5-megapixel sensor with wide dynamic range kept on
16.7 ms of sensor-side latency removed by one ported mode
200 fps from a 4K sensor in a cropped window, with crop and binning set at runtime

Measured by us on shipping camera hardware; the before-and-after recordings are shown on the call.

The datasheet has six modes. Your driver has one.

You chose the sensor for what the datasheet promised — wide dynamic range, sixty frames, a 4K window — and got a driver that runs one mode at one rate, with a register table copied from a reference board. Changing anything means a vendor ticket, and the vendor's answer is the mode you already have.

Tuning is worse. The pipeline reports statistics from a stage you cannot see, so the exposure loop you wrote never converges and nobody can tell you why. You need people who have read the pipeline's actual data flow — across eight generations of one vendor's silicon, and four vendors.

Exposure there is a ceiling, not a time. Once you know that, the tuning makes sense.

What we bring

Four things, each one measured on the hardware.

Modes the vendor did not ship

Sixty frames, binning, cropped high-speed windows. We derive the timings from the datasheet and verify them on the interface, so the mode you need exists on your board.

Frame rate recovered

When a port runs slow, the cause is in the init sequence or the pipeline, not the sensor. We trace the vendor firmware register by register and rebuild the path until the rate matches the silicon.

Tuning that converges

We know which statistics are measured where — before or after dehaze, on raw or on colour — so your loops close on data they can act on. Delivered as a report with before-and-after captures.

One driver, many boards

A genealogy of which sensors are rebrands of which, and a porting guide that collapses eight platform generations into five driver tiers, so the second port costs a fraction of the first.

Results on real cameras

Frame rate

A 5-megapixel sensor with wide dynamic range ran at a broken 6 fps on a customer-grade camera. Tracing the vendor's init sequence and rewriting the pipeline took it to 21 — a few frames short of the vendor's own closed build, with the dynamic range kept on. The recordings are the proof.

Latency

Porting a 1080p60 mode from datasheet timings cut sensor-side latency by a full frame and lifted the encoded rate on the wire by 47%. The same method gave a 4K sensor runtime crop and binning up to 200 fps. Every mode was verified on the interface, not in a log.

Image quality

A fog tuning of two cameras doubled the measurable detail on one and cut its haze by four fifths — with every cost itemised, and two vendor knobs shown to do nothing. It came with a finding the documentation omits: exposure statistics are taken upstream of dehaze, so a software tone loop cannot close on them.

The platforms

HiSilicon & GokeSigmaStarIngenicRockchip160+ sensor drivers

More than 160 sensor drivers across ten chip families, and firmware shipping on hundreds of sensor-and-SoC pairings. If your combination exists, we have probably booted it; if it does not, we know what the port costs before we start.

How an engagement works

01

Pipeline assessment

Fixed price, ten working days. You send the sensor and SoC — or a sample unit — your current driver or firmware, and the mode or picture you need. You get the measured frame rate and latency of what you have, the modes the silicon can reach, the cause of any gap, and a port plan with a fixed quote.

02

The project

Port or rewrite the driver, verify the timings on the interface, tune against before-and-after captures, and hand over the register tables with the reasoning behind every value.

03

Keep

Drivers land in your tree, or in OpenIPC if you prefer shared maintenance, with genealogy notes for the next sensor you choose.

Send the sensor and the board. In ten days you will know what frame rate it can really do.

One mail with four lines: the sensor and SoC, the mode or picture you need, what you have today, and your volume and timeline. An engineer answers with a plan, not a sales script.

Write to business@openipc.org Ask in the chat

Commercial support, OEM licensing and the other services are on the business page.