One ISP across the FPGA bridge and the GPU.
Tuned once.
BridgeSense brings up any Holoscan Sensor Bridge camera and runs one open-source ISP across the FPGA and the NVIDIA GPU, with a single tuning set on both sides. The GPU stays free for AI.
What BridgeSense does for you
Three steps, from a new camera to clean video for your AI.
Plug in a camera
Any Holoscan Sensor Bridge setup: a camera on a Lattice, Microchip or Altera bridge board, linked to Jetson, IGX or Thor over Ethernet.
Sets it up for you
- Recognises the board and the sensor
- Loads the image processing (ISP)
- Applies the tuning, adjustable live
No drivers to write, no FPGA tools, no hand-tuning per board.
Gets clean, tuned video
your AI models imaging
Frames arrive in GPU memory ready for your models, and most of the GPU stays free for AI.
Four ways a camera reaches NVIDIA today. Each locks the ISP somewhere.
In the SoC, in the sensor, in the FPGA or on the GPU. Pick a path to see where the ISP runs, what it costs you, and how BridgeSense changes it.
Sensor direct to Jetson, ISP in the SoC
- No extra chips; lowest bill of materials
- Hardware ISP: no GPU time spent on imaging
- Mature stack (Argus / V4L2), low latency
- A V4L2 driver and device tree for every new sensor
- ISP is closed: tuning goes through partners
- Short MIPI reach; cameras limited by CSI lanes
BridgeSense: open, tunable ISP and any sensor via auto-detect and the sensor agent, with cameras over Ethernet.
Sensor direct to Jetson, ISP on the GPU
- Fully software: tune or change algorithms any time
- Any algorithm the GPU can run: NR, HDR, AI-tuned
- No extra hardware
- ISP time comes out of the GPU’s AI budget
- Still a V4L2 driver per sensor; short MIPI reach
- RAW at full rate reaches the host
BridgeSense: keeps this tunability and keeps more of the GPU for AI.
HSB with the sensor’s built-in ISP
- Simplest system: no ISP to build or host
- Processed video: the GPU stays free for AI
- Long reach and many cameras over Ethernet
- Basic image quality: simple AE/AWB, little NR
- Barely tunable; locked to one sensor vendor
- YUV costs more link than RAW
BridgeSense: a full, tunable pipeline on the same bridge, and the same bring-up for these sensors too.
HSB with the ISP in the FPGA
- No extra chip; processing right at the sensor
- Cuts link load: merge or compand before Ethernet
- Deterministic latency; GPU stays free for AI
- Fabric limits what fits; full pipelines don’t
- Vendor FPGA ISPs are closed and fixed
- Every change is a rebuild and a reflash
BridgeSense: the same bridge, with a full ISP that stays tunable and upgradable from the app.
One ISP across the FPGA and the GPU
- One tuning set for the whole pipeline
- Board and sensor auto-detection; sensor agent for new sensors
- Upgrades from the app, no vendor FPGA tools
- Keeps more of the GPU for AI
- Needs a Holoscan Sensor Bridge board
- New boards need a one-time bring-up and qualification
Open core: Infinite-ISP and the app are open; Hololink stays unmodified.
One app on the host. Three jobs.
BridgeSense runs on the Holoscan SDK and processes no pixels itself. It discovers the board and sensor, configures them, starts the stream, and applies one tuning set to the whole pipeline.
Bring-up
Detects the board, Hololink version and sensor. Picks a qualified bitstream from the library and flashes it from the app, with no vendor FPGA tools on day one.
Unified imaging
One open-source ISP, Infinite-ISP, with one set of parameters and one image-quality reference, whichever bridge you use.
Library
Qualified board × sensor × bitstream combinations with real resource numbers, test results and licences, across Lattice, Microchip and Altera bridges.
Infinite-ISP
The open hardware ISP: floating-point model, bit-exact Golden Model and RTL. The open ISP at the core of BridgeSense.
CUDA ISP
The same pipeline as a Holoscan operator on the NVIDIA GPU. Proven on Jetson and x86.
LumaIQ
Analysis and tuning tooling behind the live metrics and the one-file tuning flow.
Plug in a camera.
BridgeSense works out the rest.
The bridge board announces itself; the sensor answers over I2C. BridgeSense reads both, picks the matching bitstream and sensor configuration from its library, and starts streaming. No vendor IDE, no hand-written driver.
Known sensor
Identified by its chip ID. Mode tables, register sequences and a base tuning file come straight from the library.
Unknown sensor
The Sensor Configuration Agent reads the datasheet and generates the driver, mode tables and register sequences, then validates them on the bridge. The result joins the library.
- Board auto-detection: vendor, board, Hololink version, bitstream in flash
- Sensor auto-detection over I2C through the bridge; mode stays your choice
- Qualified bitstreams flashed from the app, with a licence check and a safe fallback image
$ bridgesense bring-up
listening for boards …
✓ board found Lattice CertusPro-NX Versa Hololink 0x2606 · 1 GbE · bitstream in flash
probing sensor over I2C …
✓ sensor found Sony IMX214 id 0x0214 @ 0x10
library lookup Versa × IMX214
✓ bitstream passthrough v2606 matches flash · no reflash needed
✓ sensor config 1920×1080 @ 30 · RAW10 from library
✓ tuning file imx214_base.json
starting stream … live 622 Mb/s on 1 GbE
$ bridgesense bring-up –sensor new
probing sensor over I2C …
? sensor unknown id 0x0678 not in library
→ sensor agent reading datasheet · generating driver, mode tables, register sequences …
✓ validated on bridge IMX678 · 1936×1166 · RAW10 added to library
Colour correction LIVE
Tune once.
Live, on every board.
Every ISP module is tunable while the camera streams, from one screen, with one tuning file that travels with the sensor to every bridge.
- One set of parameter names and ranges for the whole pipeline; the app applies them for you
- Live image, 3A statistics and image-quality metrics while you tune
- A/B snapshots and presets per sensor mode
Built for cameras that can’t sit next to the GPU.
Holoscan Sensor Bridge puts the camera metres away over Ethernet. BridgeSense makes those cameras plug-and-play, tuned, and light on the GPU.
Single camera, long reach
Industrial inspection, lab and medical imaging. A tuned 1080p camera over 1 GbE, metres from the host.
High dynamic range at the edge
HDR sensors with one tuning set, for surgical and outdoor scenes.
Multi-camera on 10 GbE
Robotics and mobility: several sensors on one bridge, one tuning set across all of them.
Open core. Bitstreams delivered the way NVIDIA does it.
The ISP, the app and the build recipes are open. Finished bitstreams are hosted with a manifest and checksum and a licence step in the app, the same model NVIDIA uses for Holoscan Sensor Bridge firmware. Hololink stays unmodified, so every bitstream stays HSB-compatible.
Same chip is not the same board. For your own board we share the recipe and you build with your licence, or we build and qualify it for you.
Logos identify compatible ecosystems and do not imply endorsement. NVIDIA, Holoscan and Jetson are trademarks of NVIDIA Corporation.
Straight answers.
Do you modify NVIDIA’s Hololink IP?
No. Hololink stays unmodified, so every BridgeSense bitstream stays compatible with Holoscan Sensor Bridge.
Do I need vendor FPGA tools or licences?
No. The app installs qualified bitstreams for you, the same way NVIDIA ships Holoscan Sensor Bridge firmware.
What if my board isn’t in the library?
Same chip is not the same board. We bring up and qualify your board and sensor, and it joins the library.
Which NVIDIA hosts?
Jetson Orin and IGX today; multi-camera and 4K need a 10 or 25 GbE host such as AGX Orin or Thor with a ConnectX NIC. The host is part of pilot scoping.
Is the image quality the same on every board?
Yes, by design: one ISP, one parameter set and one image-quality reference. Measured image quality is part of the pilot deliverables.
Pilot BridgeSense on your Holoscan Sensor Bridge board.
One qualified board, one tuning set, and measured image quality and GPU time saved. Or bring your own board and sensor for bring-up and qualification.