Patent 9232158
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Active provider: Google · gemini-2.5-flash
Derivative works
Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.
Defensive Disclosure Document for US Patent 9232158
Patent Title: Large dynamic range cameras
Patent Number: US9232158B2
Priority Date: August 25, 2004
Issue Date: January 5, 2016
Expiration Date: February 17, 2026 (Patent has expired as of 2026-02-17)
Current Date: June 6, 2026
Specialization: Defensive Publishing Strategy
Objective: To expand the public domain of prior art related to large dynamic range camera systems by disclosing various derivative implementations and combinations, thereby rendering incremental improvements in this field obvious or non-novel for future patent applications. This document focuses on variations of the core inventive concept described in US9232158B2, namely, a multi-channel digital camera system with independently controlled, simultaneous integration times for each channel, and a processing component to combine their data for a wide dynamic range image.
Core Inventive Concept (Derived from Abstract and Summary):
A digital camera comprising:
- A plurality of channels, each channel including:
- An optics component.
- A sensor comprising an array of photo-detectors.
- A processing component operatively coupled to the plurality of channels.
- The processing component configured to:
- Separately and simultaneously control an integration time of each channel, wherein a first integration time of a first channel is different from a second integration time of a second channel.
- Combine data from the plurality of channels to generate an image with an expanded dynamic range.
1. Material & Component Substitution
Derivative 1.1: Alternative Sensor Technologies
- Enabling Description: The digital camera system employs multiple channels, where each channel's sensor array utilizes different semiconductor materials or architectures optimized for specific light conditions. For instance, a "long integration time" channel could incorporate Indium Gallium Arsenide (InGaAs) sensors for enhanced near-infrared (NIR) sensitivity and low-light performance, while "short integration time" channels utilize silicon-germanium (SiGe) heterojunction phototransistors for high speed and saturation tolerance in bright conditions. The optics components would be correspondingly tailored for the spectral response of these materials. The processing component combines the spectrally and temporally diverse data streams into a single high dynamic range image.
graph TD
A[Light Input] --> B{Beam Splitter / Filter Array}
B --> C1(NIR Channel Optics - Long Int. Time)
C1 --> D1(InGaAs Sensor Array)
D1 --> E1{Channel Processor NIR}
B --> C2(Visible Channel Optics - Short Int. Time)
C2 --> D2(SiGe Sensor Array)
D2 --> E2{Channel Processor Visible}
E1 --> F(HDR Image Fusion Processor)
E2 --> F
F --> G[Large Dynamic Range Output Image]
Derivative 1.2: Liquid Crystal Lenses and Tunable Filters
- Enabling Description: Each optics component in the multi-channel system is replaced with a dynamically reconfigurable liquid crystal lens (LCL) system, allowing for electronic control of focal length and aperture (f-number) without mechanical movement. Furthermore, each channel incorporates an electro-optical tunable filter (e.g., based on acousto-optic deflectors or liquid crystal tunable filters) instead of fixed color filters. This enables the processing component to not only control integration time but also dynamically adjust the spectral bandpass and optical collection parameters of each channel in real-time, optimizing for scene content or specific light conditions (e.g., dynamically switching a channel from broadband visible to a narrow IR band).
graph TD
A[Light Input] --> B(Scene Analysis)
B -- Control Signals --> C1(Channel 1: LCL + Tunable Filter)
C1 --> D1(Sensor 1)
D1 --> E1{Channel Processor 1}
B -- Control Signals --> C2(Channel 2: LCL + Tunable Filter)
C2 --> D2(Sensor 2)
D2 --> E2{Channel Processor 2}
E1 --> F(HDR Image Fusion Processor)
E2 --> F
F --> G[Large Dynamic Range Output Image]
Derivative 1.3: Ferroelectric RAM (FRAM) Integrated Pixels
- Enabling Description: To enhance in-pixel charge storage capacity and non-volatility, the photo-detector array in each channel integrates ferroelectric random-access memory (FRAM) directly at the pixel level. This allows for multi-bit charge storage per pixel, effectively extending the dynamic range within a single integration period by quantizing charge accumulation. Different channels can then utilize distinct FRAM configurations or readout strategies (e.g., one channel uses a deeper well depth simulation via FRAM for long integration, another a shallower one for short integration) that are controlled by the processing component, further refining the simultaneous multi-exposure concept.
classDiagram
class ChannelProcessor {
+controlIntegrationTime()
+readPixelData()
}
class PhotoDetectorArray {
+pixels: Pixel[*]
+capturePhotons()
}
class Pixel {
+photoChargeStorage: FRAMCell
+accumulateCharge()
+transferCharge()
}
class FRAMCell {
+storeCharge(charge)
+readCharge()
+nonVolatileStorage
}
PhotoDetectorArray --> Pixel : contains
Pixel --> FRAMCell : uses
ChannelProcessor --> PhotoDetectorArray : controls & reads
Derivative 1.4: Multi-Junction Photodiodes for Wavelength-Dependent Integration
- Enabling Description: Each sensor array utilizes multi-junction photodiodes, where different pn-junctions are stacked to absorb different spectral bands at varying depths within the semiconductor. The processing component is configured to control the integration time independently for each junction layer within a pixel, effectively creating "sub-channels" within a single physical pixel. For example, the blue-sensitive top junction could have a shorter integration time, while the red-sensitive deeper junction has a longer integration time. This allows for simultaneous multi-spectral, multi-exposure capture at a single pixel location, mitigating spatial alignment issues inherent in multiple physically separated channels.
stateDiagram-v2
state "Multi-Junction Pixel" as Pixel {
state "Blue_Junction" as BJ {
BJ --> Short_Int : capture
Short_Int --> Read_Out_B : integrated
}
state "Green_Junction" as GJ {
GJ --> Medium_Int : capture
Medium_Int --> Read_Out_G : integrated
}
state "Red_Junction" as RJ {
RJ --> Long_Int : capture
Long_Int --> Read_Out_R : integrated
}
}
Read_Out_B --> Combine_Signals
Read_Out_G --> Combine_Signals
Read_Out_R --> Combine_Signals
Combine_Signals --> Output_HDR_Pixel
2. Operational Parameter Expansion
Derivative 2.1: Terahertz (THz) Imaging System with Ultra-Fast Gating
- Enabling Description: The multi-channel concept is applied to Terahertz (THz) imaging for industrial inspection. Each channel comprises THz optics (e.g., silicon lenses or metamaterial lenses) and a THz sensor array (e.g., based on bolometers or plasmonic photodetectors). The "integration time" is replaced by an ultra-fast electrical gating pulse applied to each sensor array, controlling the duration of THz wave interaction. One channel uses femtosecond gating for high spatial resolution and transient event capture, while another uses picosecond gating for deeper penetration or material characterization where signal accumulation is critical. The processing component synchronizes these ultra-fast acquisitions and fuses the data for high dynamic range THz images, useful for detecting defects in composites or package contents.
sequenceDiagram
participant THz_Src as THz Source
participant Scene
participant Ch1_Optics as Channel 1 Optics (Femto-Gate)
participant Ch1_Sensor as Channel 1 Sensor
participant Ch2_Optics as Channel 2 Optics (Pico-Gate)
participant Ch2_Sensor as Channel 2 Sensor
participant Proc as THz Fusion Processor
THz_Src ->> Scene: Emit THz Pulse
Scene -->> Ch1_Optics: Reflected/Transmitted THz
Scene -->> Ch2_Optics: Reflected/Transmitted THz
Ch1_Optics ->> Ch1_Sensor: Direct THz to sensor
Ch2_Optics ->> Ch2_Sensor: Direct THz to sensor
Proc ->> Ch1_Sensor: Apply Femtosecond Gate (simultaneous)
Proc ->> Ch2_Sensor: Apply Picosecond Gate (simultaneous)
Ch1_Sensor -->> Proc: Output Data (short integration)
Ch2_Sensor -->> Proc: Output Data (long integration)
Proc ->> Proc: Fuse Data for HDR THz Image
Derivative 2.2: Deep-Space Astronomy Imager with Milli-Second to Hour Integration Times
- Enabling Description: A digital camera system designed for deep-space astronomy utilizes multiple channels to capture celestial objects with vastly different brightness levels. One channel employs highly sensitive electron-multiplying CCD (EMCCD) or Superconducting Nanowire Single-Photon Detector (SNSPD) arrays with integration times ranging from milliseconds to tens of seconds to capture transient phenomena (e.g., fast radio bursts, occultations). A second channel, equipped with cryogenically cooled, ultra-low dark current CMOS sensors, operates with integration times spanning minutes to hours to accumulate faint light from distant galaxies or nebulae. A third channel, with standard CCDs, handles intermediate brightness. All channels image the same celestial field simultaneously, and a dedicated processing unit performs noise reduction, cosmic ray rejection, and HDR fusion across the enormous dynamic range.
graph LR
A[Celestial Input] --> B{Beam Splitter / Telescope Focus}
B --> C1(Ultra-Fast Channel: EMCCD/SNSPD - ms to s)
C1 --> D1(Channel Processor - Transient)
B --> C2(Intermediate Channel: Standard CCD - s to min)
C2 --> D2(Channel Processor - Mid-Range)
B --> C3(Deep-Field Channel: Cooled CMOS - min to hrs)
C3 --> D3(Channel Processor - Faint Objects)
D1 --> E(Deep-Space HDR Fusion Unit)
D2 --> E
D3 --> E
E --> F[Scientific HDR Image Output]
Derivative 2.3: Microfluidic Flow Analysis Camera with Microsecond Integration
- Enabling Description: For high-speed microfluidic analysis, a multi-channel camera system is implemented where each channel captures fluorescent markers in a microchannel. The optics components are high-numerical-aperture microscope objectives. The sensors are high-frame-rate CMOS arrays with sub-microsecond integration time control. One channel operates with a very short integration time (e.g., 100 ns) to freeze rapid particle motion, preventing motion blur in fast flows. Another channel uses a slightly longer integration time (e.g., 1 µs) to enhance signal from dimmer markers or areas with lower concentrations. The processing component simultaneously captures and combines these images, enabling high dynamic range particle tracking and intensity analysis in complex microfluidic environments, particularly useful where both bright and faint signals coexist in fast flows.
flowchart TD
A[Microfluidic Flow with Markers] --> B(Microscope Optics)
B -- Split Light --> C1(Channel 1: High-Speed CMOS @ 100ns Int. Time)
C1 --> D1{FPGA Processor - Motion Capture}
B -- Split Light --> C2(Channel 2: High-Speed CMOS @ 1us Int. Time)
C2 --> D2{FPGA Processor - Intensity Capture}
D1 --> E(Real-Time HDR Fusion Engine)
D2 --> E
E --> F[Combined High-Resolution Flow Data]
3. Cross-Domain Application
Derivative 3.1: Autonomous Vehicle Multi-Spectral Perception System
- Enabling Description: The multi-channel camera system is integrated into an autonomous vehicle's perception stack. One channel is optimized for visible light with short integration times to handle bright daylight and glare, ensuring clear detection of road signs and other vehicles. A second channel, using long integration times, is sensitive to near-infrared (NIR) and short-wave infrared (SWIR) for night vision and penetrating fog or heavy rain, enhancing pedestrian and obstacle detection in adverse conditions. A third channel might be tuned for specific spectral bands to detect brake lights, emergency vehicle lights, or road surface conditions. The processing component fuses this multi-spectral, multi-exposure data in real-time, providing a robust, high dynamic range environmental perception for autonomous driving decisions.
graph TD
A[Road Environment] --> B{Vehicle Sensor Suite - Light Input}
B --> C1(Visible Channel - Short Int. Time)
C1 --> D1(Visible Light Sensor)
D1 --> E1{Perception Module - Daylight}
B --> C2(NIR/SWIR Channel - Long Int. Time)
C2 --> D2(NIR/SWIR Sensor)
D2 --> E2{Perception Module - Night/Fog}
E1 --> F(HDR Fusion & Object Detection)
E2 --> F
F --> G[Autonomous Driving Decision Engine]
Derivative 3.2: Precision Agriculture Crop Health Monitoring Drone
- Enabling Description: A drone-mounted multi-channel camera system is deployed for precision agriculture. One channel captures images in the visible spectrum with short integration times for general canopy structure and disease detection under varying sunlight. A second channel focuses on specific narrow-band wavelengths (e.g., red-edge, NIR) critical for Normalized Difference Vegetation Index (NDVI) calculation and early stress detection. This channel uses longer integration times to gather sufficient spectral information, especially under partial cloud cover or during dawn/dusk operations. A third channel may capture thermal infrared (TIR) with its own optimized integration for water stress detection. The processing component combines these images, generating high dynamic range, multi-spectral maps of crop health, irrigation needs, and disease spread.
flowchart LR
A[Crop Field] --> B(Drone Flight Path)
B --> C{Multi-Spectral Camera Payload}
C -- Visible Light --> D1(RGB Channel - Short Int. Time)
D1 --> E1[Visible Image Processor]
C -- Red-Edge/NIR --> D2(NDVI Channel - Long Int. Time)
D2 --> E2[NDVI Image Processor]
C -- Thermal IR --> D3(Thermal Channel - Optimized Int. Time)
D3 --> E3[Thermal Image Processor]
E1 --> F(Cloud-Based HDR & Analytics Platform)
E2 --> F
E3 --> F
F --> G[Crop Health Report & Actionable Insights]
Derivative 3.3: Industrial Quality Control for Pharmaceutical Manufacturing
- Enabling Description: In pharmaceutical manufacturing, a multi-channel camera system is used for automated quality control of pills or vials on a high-speed conveyor belt. One channel uses visible light with short integration times to detect surface imperfections, color variations, or print quality. A second channel employs UV-fluorescence imaging with longer integration times to detect active pharmaceutical ingredients (APIs) or excipient distributions that fluoresce under UV light. A third channel uses transmission imaging (e.g., X-ray or specific IR wavelengths) with tailored integration for internal defect detection. The processing component simultaneously acquires data from all channels, combining them to perform comprehensive, high dynamic range quality assurance, identifying defects that would be missed by single-spectrum or single-exposure methods.
graph LR
A[Pill on Conveyor] --> B{Illumination & Optics System}
B -- Visible --> C1(Visible Channel - Short Int.)
C1 --> D1(Image Processor - Surface QA)
B -- UV-A --> C2(UV-Fluor. Channel - Long Int.)
C2 --> D2(Image Processor - API Detect)
B -- X-Ray --> C3(X-Ray Trans. Channel - Tailored Int.)
C3 --> D3(Image Processor - Internal Defect)
D1 --> E(Integrated Quality Control System)
D2 --> E
D3 --> E
E --> F{Pass/Fail Decision & Ejection}
4. Integration with Emerging Tech
Derivative 4.1: AI-Driven Optimization of Integration Times
- Enabling Description: The multi-channel camera system is enhanced with an embedded AI inference engine. Instead of fixed or user-selected integration times, the AI analyzes real-time scene content, lighting conditions, and desired output characteristics (e.g., target dynamic range, specific object of interest, motion blur tolerance). Using deep learning models (e.g., a Convolutional Neural Network trained on diverse HDR scenes), the AI dynamically adjusts the integration times of each channel for optimal image acquisition in subsequent frames. This allows for adaptive exposure control that goes beyond simple histogram analysis, predicting and compensating for complex lighting changes and motion, further enhancing the effective dynamic range and image quality.
sequenceDiagram
participant Scene
participant Sensors as Multi-Channel Sensors
participant PreProc as Pre-Processing (e.g., initial metering)
participant AI_Engine as AI Inference Engine
participant IntControl as Integration Time Controller
participant Proc as HDR Image Fusion Processor
participant Output as Output Image
Scene ->> Sensors: Light Input
Sensors ->> PreProc: Raw Sensor Data
PreProc ->> AI_Engine: Scene Metadata / Low-Res Preview
AI_Engine ->> AI_Engine: Analyze scene, predict optimal Int. Times
AI_Engine ->> IntControl: New Integration Times (T1, T2, ..., Tn)
IntControl ->> Sensors: Apply new Integration Times (simultaneous capture)
Sensors ->> Proc: Raw Sensor Data (optimized exposure)
Proc ->> Output: Fused HDR Image
Derivative 4.2: IoT-Enabled Remote Monitoring with Real-Time Data Streaming
- Enabling Description: The multi-channel digital camera is integrated into an Internet of Things (IoT) network for remote surveillance or environmental monitoring. Each channel's processing component performs localized preprocessing (e.g., noise reduction, initial HDR merging) and then encrypts and streams segmented high dynamic range image data (e.g., specific regions of interest or compressed video streams) via a secure IoT gateway. IoT sensors (e.g., ambient light sensors, temperature, humidity) co-located with the camera provide contextual metadata that influences the camera's integration time settings via a cloud-based control plane. This enables real-time adaptive HDR imaging and alerts based on environmental conditions, with blockchain potentially used for secure data provenance and integrity verification of the streamed image data.
graph TD
A[Scene] --> B(Multi-Channel Camera)
B --> C{Local Pre-Processing & Encryption}
C --> D[IoT Gateway]
D --> E(Cloud Control Plane & Storage)
C -- Contextual Data --> E
F[Ambient Light Sensor] -- Env. Data --> E
E -- Integration Time Commands --> B
E --> G[Blockchain Ledger]
G -- Verifies Data Provenance --> D
E --> H[Remote Monitoring Dashboards]
Derivative 4.3: Edge Computing for Decentralized HDR Fusion
- Enabling Description: Instead of a single centralized processing component, the HDR fusion logic is distributed across edge computing nodes, potentially even within each channel's dedicated processor or a local system-on-chip (SoC) adjacent to the sensor arrays. Each channel processor performs initial image correction and then transmits partially processed data (e.g., tone-mapped sub-images, statistical scene descriptors, or feature maps) to a lightweight edge orchestrator. This orchestrator, running on a low-power microcontroller, performs the final, adaptive HDR merging and local storage/transmission. This reduces bandwidth requirements to a central cloud, improves latency for real-time applications, and enhances privacy by processing sensitive data closer to the source. The AI-driven optimization (Derivative 4.1) could also reside at the edge.
flowchart TD
A[Scene] --> B1(Channel 1 Sensor+Optics)
A[Scene] --> B2(Channel 2 Sensor+Optics)
B1 --> C1{Channel 1 Edge Processor - Partial HDR}
B2 --> C2{Channel 2 Edge Processor - Partial HDR}
C1 --> D(Edge Orchestrator - Final HDR Fusion)
C2 --> D
D --> E[Local Storage / Reduced Bandwidth Tx]
D --> F{AI/ML for Adaptive Control}
F --> C1
F --> C2
5. The "Inverse" or Failure Mode
Derivative 5.1: Fail-Safe Low-Power Monochromatic Mode
- Enabling Description: In the event of a critical system failure (e.g., primary power loss, channel malfunction, thermal overload), the multi-channel camera system automatically switches to a fail-safe, low-power monochromatic imaging mode. This involves disabling all but one (e.g., the green channel, which often has the highest responsivity) or a pre-selected broadband channel, and operating it at a fixed, medium integration time. Color filtering, if present, is bypassed or a clear aperture is used. The image processing component simplifies to basic grayscale conversion and minimal noise reduction, consuming significantly less power and computational resources, ensuring continuous, albeit reduced, operational capability for critical functions like emergency navigation or basic surveillance.
stateDiagram-v2
state "Normal Operation (HDR Color)" as Normal {
Normal --> Critical_Failure : Fault Detected
}
state "Critical Failure" as CF {
CF --> Low_Power_Mono : Activate Fail-Safe
}
state "Low-Power Monochromatic Mode" as LPMM {
LPMM : Disable excess channels
LPMM : Fixed Medium Integration Time
LPMM : Simple Grayscale Processing
LPMM --> Normal : System Recovered
}
Critical_Failure --> Critical_Failure : Fault Persists
Low_Power_Mono --> Low_Power_Mono : Operating in Fail-Safe
Derivative 5.2: Limited-Functionality "Preview" Mode for Resource-Constrained Devices
- Enabling Description: For integration into resource-constrained devices (e.g., low-end IoT devices, wearables with minimal battery), the multi-channel camera system can operate in a limited-functionality "preview" mode. In this mode, only two channels are active: one with a short integration time (for bright areas) and one with a long integration time (for dark areas), both potentially using a Bayer pattern or simpler color filters to save cost/complexity. The image processing component performs a highly optimized, computationally inexpensive HDR merge (e.g., simple linear blending or selection based on saturation thresholds), generates a lower-resolution output image, and bypasses advanced image adjustments (sharpening, noise reduction). This provides a usable, albeit less sophisticated, HDR image while minimizing power consumption, memory footprint, and processing load.
flowchart LR
A[Power Constraints / Low Resources] --> B(Mode Selector)
B -- Select "Preview" --> C{Two Active Channels}
C -- Short Int. --> D1(Channel 1 - Low Res)
C -- Long Int. --> D2(Channel 2 - Low Res)
D1 --> E(Optimized HDR Merger - Edge)
D2 --> E
E --> F[Low-Res HDR Preview Output]
F -- No Advanced Processing --> G(Reduced Power/CPU Load)
Derivative 5.3: Controlled Saturation "Clipping" Mode for Specific High-Brightness Targets
- Enabling Description: In applications where certain very bright objects are the primary targets (e.g., welding arc monitoring, solar panel inspection, medical endoscopy with bright light sources), the system can enter a "controlled saturation" mode. Here, the processing component actively allows the shorter integration time channels to saturate in areas outside the primary target's region of interest, effectively "clipping" unimportant bright areas to save processing bandwidth and storage. Simultaneously, the longer integration time channels are still used to capture details in darker, surrounding areas. The HDR fusion algorithm is modified to prioritize data from the short exposure channels within defined target regions, and from long exposure channels elsewhere. This inverse approach optimizes for critical bright features while still retaining some dynamic range in the context.
graph TD
A[Scene with Bright Target] --> B(Multi-Channel Input)
B -- Short Int. Data --> C1(Channel Short - High Brightness Data)
B -- Long Int. Data --> C2(Channel Long - Low Brightness Data)
C1 --> D{Processor: Identify Target Region}
C2 --> D
D --> E{Modified HDR Fusion}
E -- Prioritize C1 in Target Region --> F(Output Image with Controlled Saturation)
E -- Prioritize C2 in Non-Target Region --> F
Combination Prior Art Scenarios with Open-Source Standards
These scenarios describe how the principles of US9232158B2 could be combined with existing open-source standards to create new prior art, making future improvements obvious.
Integration with OpenCV for Real-Time HDR Processing on Embedded Linux Systems:
- Description: A multi-channel digital camera system (as described in US9232158B2) is implemented on an embedded system running a Linux kernel, such as a Raspberry Pi or NVIDIA Jetson. The image acquisition from the multiple sensor channels is managed by a custom driver or V4L2 (Video4Linux2) interface. The processing component's HDR fusion and image pipeline functionalities are implemented using the publicly available OpenCV library (e.g.,
cv::createMergeDebevec,cv::createMergeMertens, or custom blending algorithms). This combination openly demonstrates real-time, software-defined HDR image acquisition and fusion from simultaneous multi-exposure channels using a widely adopted open-source computer vision framework, establishing prior art for software-based HDR solutions on commodity hardware. - Prior Art Value: Establishes the combination of hardware-accelerated multi-channel capture with accessible, open-source software libraries for HDR reconstruction. Any future patent attempting to claim novel HDR fusion algorithms or real-time implementation on embedded Linux platforms, without a truly inventive step beyond parameter tuning or minor algorithmic modifications, would be rendered obvious by this disclosure.
- Description: A multi-channel digital camera system (as described in US9232158B2) is implemented on an embedded system running a Linux kernel, such as a Raspberry Pi or NVIDIA Jetson. The image acquisition from the multiple sensor channels is managed by a custom driver or V4L2 (Video4Linux2) interface. The processing component's HDR fusion and image pipeline functionalities are implemented using the publicly available OpenCV library (e.g.,
HDR Camera System with GStreamer for Modular Video Pipeline:
- Description: The multi-channel camera system (US9232158B2) integrates with GStreamer, an open-source multimedia framework, to create a flexible and modular video processing pipeline. Each camera channel feeds its raw video stream (e.g., MIPI CSI-2 interface) into a GStreamer source element. Separate GStreamer elements are then used for individual channel processing (e.g., gain adjustment, demosaicing if applicable, black level correction). A custom GStreamer plugin or a combination of existing plugins performs the real-time HDR merging of the multiple simultaneous exposures. The final HDR video stream can then be encoded (e.g., H.264 using
x264encplugin) and transmitted over a network using standard GStreamer sink elements. This demonstrably implements the core inventive concept within a highly extensible open-source video processing framework. - Prior Art Value: Showcases a configurable and modular approach to building HDR cameras using standard open-source multimedia pipelines. This would preempt patents on specific architectural arrangements of HDR camera pipelines that leverage well-known GStreamer patterns for source, filter, and sink elements, or on general real-time HDR video processing in such an environment.
- Description: The multi-channel camera system (US9232158B2) integrates with GStreamer, an open-source multimedia framework, to create a flexible and modular video processing pipeline. Each camera channel feeds its raw video stream (e.g., MIPI CSI-2 interface) into a GStreamer source element. Separate GStreamer elements are then used for individual channel processing (e.g., gain adjustment, demosaicing if applicable, black level correction). A custom GStreamer plugin or a combination of existing plugins performs the real-time HDR merging of the multiple simultaneous exposures. The final HDR video stream can then be encoded (e.g., H.264 using
Sensor Control via I2C/SPI and Data Output via USB using Standard Linux Drivers:
- Description: A multi-channel camera system as per US9232158B2 utilizes standard open-source Linux kernel drivers for sensor control and data transfer. The integration time control for each channel's sensor is managed via I2C or SPI communication protocols using existing Linux device tree bindings and kernel modules. Raw image data from the multiple channels is aggregated and then streamed out via a USB interface, presented as a standard UVC (USB Video Class) device. The HDR merging algorithm, running either on the host CPU or a programmable logic device, processes these UVC streams. This emphasizes the use of widely available open-source hardware interfaces and drivers to implement the core functionality of independent integration time control and data acquisition from multiple sensors.
- Prior Art Value: Documents the use of common, open-source communication protocols (I2C, SPI, USB) and their associated Linux drivers to control multi-channel image sensors with independent integration times. This would render obvious any attempt to patent the "interfacing" or "control mechanism" of such a system if it merely relies on these well-established and publicly documented standards without a novel underlying hardware or protocol invention.
Generated 6/6/2026, 9:55:47 AM