# Infinite-ISP: a Python camera pipeline for ISP algorithm work

> Infinite-ISP is a Python model of a camera image signal processor, published by 10x Engineers, that turns sensor RAW frames into RGB through replaceable modules. It is a development and tuning platform, not a production camera stack.

**10x-Engineers/Infinite-ISP** — A camera ISP (image signal processor) pipeline that contains modules with simple to complex algorithms implemented at the application level.

- Repository: https://github.com/10x-Engineers/Infinite-ISP
- Website: http://www.10xengineers.ai
- Stars: 393 · Forks: 112
- Language: Python
- License: Apache-2.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/10x-engineers-infinite-isp

## What Infinite-ISP is for, and who should care

An image signal processor sits between a sensor and whatever consumes the picture. The sensor hands over a RAW Bayer frame, and the ISP has to correct defective pixels, subtract a black level, apply white balance gains, interpolate the missing colour channels, denoise, and decide exposure. Infinite-ISP is a Python implementation of that chain, described in the README as a collection of camera pipeline modules "implemented at the application level for converting an input RAW image from a sensor to an output RGB image".

The audience is narrow and specific. If you are an ISP algorithm developer who wants to prototype a demosaicing variant, an auto white balance method or a denoiser without touching RTL or a vendor SDK, this repository gives you the surrounding stages for free. If you are building a product camera and need something to ship, this is the wrong layer: the README frames the project as a platform for algorithm development, and the hardware side lives in separate repositories.

The stated objective is to centralize open source ISP work in one place so that conventional algorithms and deep learning approaches can be compared under the same pipeline. That is an editorial position as much as a technical one, and it shapes the code: modules are meant to be swapped rather than tuned in place.

## How the pipeline is put together

The repository is a flat Python project. The entry points are infinite_isp.py, isp_pipeline.py and isp_pipeline_mulitple_images.py at the top level, with the actual stages under modules/ and shared helpers under util/. Parameters come from config/ as YAML, which is why PyYAML is in requirements.txt alongside numpy, scipy, matplotlib, rawpy and tqdm.

rawpy is the interesting dependency. It means the pipeline reads RAW files rather than only synthetic arrays, and in_frames/ and out_frames/ exist as the working directories for that flow. The README's architecture diagram names the stages of the v1.1 pipeline, and the feature comparison table lists them explicitly: Bayer-safe cropping, dead pixel correction based on a modified Yongji et al. dynamic defective pixel correction method, black level correction from config, an OECF lookup table from config, digital gain from config, Bayer noise reduction using the green channel guiding denoising method by Tan et al., white balance gains from config, and CFA interpolation using the Malvar-He-Cutler demosaicing algorithm.

Above those sit the 3A algorithms. The table lists AE and AWB, with auto white balance offering three selectable methods: grey world, norm 2 and a PCA algorithm. That is the part of the design worth noting. Most of the pipeline is parameter-driven, so the interesting comparison surface is the 3A block and whatever algorithm module you replace. A stage that reads its gains from a config file is reproducible; a stage that estimates them is where your work happens.

## Installing Infinite-ISP and running a first RAW frame

There is no package on PyPI and no install script in the README. The README points at the repository, so the practical route is a clone plus a pinned dependency install. The pins in requirements.txt are specific: numpy 1.21.5 and scipy 1.7.3 are older releases, so use a virtual environment rather than your system Python.

```bash
git clone https://github.com/10x-Engineers/Infinite-ISP.git
cd Infinite-ISP
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
```

After that, the dependency list installs matplotlib, numpy, PyYAML, rawpy, scipy and tqdm. If rawpy fails to build, that is a wheel availability problem for your Python version rather than a problem with the project.

Config lives in config/ and is YAML, which is what the black level, OECF, digital gain and white balance stages read. The single-image entry point is infinite_isp.py:

```bash
python infinite_isp.py
```

The README does not document command line flags for this script, so what you should see depends on the paths hardcoded or configured in that file and in config/. Expect a RAW file to be read from in_frames/ and an RGB result to be written to out_frames/, with progress reported through tqdm. For a batch, isp_pipeline_mulitple_images.py is the corresponding entry point. If you want to inspect the stages without running the whole chain, isp_pipeline.py is where the module sequence is assembled.

## The gaps you will hit: lens shading, access-gated repositories, and stale pins

The feature comparison table is honest about one missing stage: lens shading correction is marked "To Be Implemented". That is not a cosmetic omission. Lens shading correction compensates for brightness falloff toward the corners of a frame, and without it wide-angle or small-sensor captures will show a visible vignette that no amount of white balance tuning fixes. If your sensor has significant shading, you are adding a module before you can evaluate anything else.

The second constraint is distribution. The README lists eight repositories in the project family, and the RTL Verilog design, the automated testing framework and the FPGA implementation for the Xilinx Kria KV260 are all behind a Google Forms access request. The Python algorithm model is open; the hardware path is not. Anyone planning to take a Python algorithm through to a bit-accurate hardware implementation should treat that gate as a scheduling risk, not a formality.

Third, the pins. numpy 1.21.5 and scipy 1.7.3 are old enough that other libraries in a modern environment will conflict with them. You can relax them, but then you are running a configuration the project did not pin, and any numerical difference you see is yours to explain. The latest release in the README is v1.1 from 2023-11-13, while the last push to main was on 2026-06-08, so the tagged release and the current tree are not the same thing.

## Infinite-ISP compared with openISP

The README does the comparison itself, against openISP, and the difference in approach is visible in the table. Where openISP implements anti-aliasing filtering and chroma noise filtering, Infinite-ISP lists neither, but adds OECF with a config-driven lookup table, Bayer-safe cropping, and the 3A block. openISP's digital gain stage is described as brightness and contrast control; Infinite-ISP's takes gains from the config file.

That contrast is the real distinction. Infinite-ISP pushes more decisions into configuration and calibration, which makes runs reproducible and makes the 3A algorithms the only stage that estimates its own parameters. openISP, by the table, keeps more of the behaviour inside the processing stages. If your goal is to compare demosaicing variants under identical upstream conditions, Infinite-ISP's config-driven stages are the better fit. If you want a compact reference where each stage does its own thing end to end, openISP is closer to that shape.

Both use Malvar-He-Cutler for CFA interpolation, so that stage is not a differentiator between them.

## Licence, maintenance and upgrade cost

The repository carries Apache-2.0, and there is a separate NOTICE file at the top level. Apache-2.0 includes an explicit patent grant and requires that NOTICE contents be preserved in distributions, so if you fork the pipeline into a product, read both files together rather than treating the licence identifier as the whole story. Nothing here is legal advice; the point is that the NOTICE file exists and is not decorative.

Upgrade cost is dominated by the dependency pins and the release cadence. Two tagged releases exist in the README, v1.0 from 2022-12-16 and v1.1 from 2023-11-13, with a pilot v0.1 before them. The last push to main was on 2026-06-08, which is more than six months before today's date, so treat the tree as updated at that point rather than continuously moving. Because the pipeline is assembled in isp_pipeline.py and parameterised through config/, a module you add is yours to maintain across any upstream change to that assembly file. The .pre-commit-config.yaml and .pylintrc at the top level indicate the project enforces lint and formatting conventions, so contributions that skip them will not match the repository's own tooling.

## Conclusion

Adopt Infinite-ISP if you are writing or comparing ISP algorithms in Python and want a pipeline that already has dead pixel correction, black level correction, white balance, demosaicing, Bayer noise reduction and AE/AWB stages wired together, with parameters coming from config files. Do not adopt it if you need a shipping camera stack for a product: the README states that lens shading correction is still to be implemented, and the RTL, automated testing and FPGA repositories are behind an access request form rather than open. Before committing, check the Apache-2.0 LICENSE and NOTICE files for what they cover, confirm that requirements.txt pins numpy 1.21.5 and scipy 1.7.3 against your Python version, and run one RAW frame through infinite_isp.py to see whether the default config in config/ produces an image you can compare against your own reference.

## FAQ

### What does ISP stand for in Infinite-ISP?

ISP stands for image signal processor. The README describes Infinite-ISP as a full-stack ISP development platform and the algorithm repository as camera pipeline modules that convert an input RAW image from a sensor to an output RGB image.

### What is an ISP used for?

It processes the RAW Bayer frame coming from a sensor into a viewable RGB image. In Infinite-ISP that means cropping, dead pixel correction, black level correction, OECF, digital gain, Bayer noise reduction, white balance and CFA interpolation, plus AE and AWB.

### Can an ISP see pictures?

No. The pipeline in this repository operates on RAW image data read through rawpy and writes RGB output frames; it is image processing code, not a vision or recognition system.

### What are the two types of ISP in this project?

The README does not classify ISPs into two types. It does separate the software side, the Python algorithm model and fixed-point reference model, from the hardware side, the RTL design and the FPGA implementation for the Xilinx Kria KV260.

## Sources

- [10x-Engineers/Infinite-ISP on GitHub](https://github.com/10x-Engineers/Infinite-ISP)
- [License: Apache-2.0](https://github.com/10x-Engineers/Infinite-ISP/blob/main/LICENSE)
- [Project website](http://www.10xengineers.ai)
- [README](https://github.com/10x-Engineers/Infinite-ISP/blob/main/README.md)
- [Releases](https://github.com/10x-Engineers/Infinite-ISP/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/10x-engineers-infinite-isp