How Revela ISP started

14 August 2026

In 2004 I started to work for Apical, a startup focused on image processing.

I was implementing all possible image processing algorithms in software on all possible HW, from ordinary embedded systems up to different accelerators and DSPs. And in all cases these were very difficult tasks, with unpacking 2D data flow into processing pipelines, with balancing between packing numerous operations and tight memory budget and DMA orchestration. And I spent 12 years doing that, and as a result my mind converged to some standard approaches that could be automated. And roughly 15 years ago at Apical I started to think that almost any image processing algorithm could be automatically converted into efficient SW or even HW from its mathematical model. And at that time I wrote my first prototype of a compiler that compiles Matlab code into efficient line-based processing in C. And it worked. But company plans changed with a refocus from SW to HW, and I was distracted with writing all possible image sensor control algorithms (AWB, AE, AF and others) and writing efficient calibration software. These were challenging and interesting tasks, but I never had a chance to come back to my ideas of compilers for image processing. And in 2016 the company was acquired by ARM.

Restructuring followed, and I found myself in a position where I make no difference in the company. So I left and decided to start my own company, spending several years building electronics products until covid hit hard and I lost everything. And covid hit exactly where I stood: chip manufacturing. The components my products needed disappeared, and that supply did not recover until 2024.

In the last three years I was fully in semiconductors and in a startup again, with learning, learning and learning. My main tasks were handling full processes from RTL to GDSII and to tapeout, and for different PDKs and processes. This was an amazing journey through the world of unknowns and complex things, making them clear, universal and simple. And the main focus was on using open source tools to build real chips. And this is how I started to love the open source world.

Over these years I was thinking that imaging had died, partly migrating into AI-specific processing.

But at some point I decided to resurrect the idea of generating image processing code from mathematical models, and I wrote np2hw, an open source project that takes Python code with numpy and generates line-based image processing Verilog code that works in a simulator and produces bit exact results. It worked, and most interestingly, when I posted about this I saw a big resonance, people reacted. So I decided this is something useful and needed, and I started to develop it further.

Meanwhile at some moment I was approached through a recruiter by some company doing stereo glasses. They talked about a fixed contract to solve some problem they experienced with colors, with their ISP and sensor. The interview went too good: I demonstrated all possible sensor and ISP related knowledge, with things and issues nobody knows about. And as a result the company was able to solve their problems themselves without offering me a contract, but they were highly impressed with my knowledge. Welcome to the open world.

I made my conclusions, and actually I am not worrying, as that company just passed one bump on a long bumpy road. They just do not see the next bump yet, but when they hit it they will know who to ask. And I realised there are plenty of people in the world doing camera pipelines and working with all kinds of sensors, who think making an ISP in HW is the biggest challenge, and they have no idea what other problems they are facing and how to solve them. But I know those problems too well.

I thought a little, especially considering how RISC-V bloomed, and realised I can do similar with an open source ISP.

I decided I will do the real HW ISP, but in Python with numpy, and will progress it together with np2hw capabilities, with plans to build all stages with all possible pipelines, covering different sensors and their calibration. And I could also finally give a chance to some of my image processing ideas left behind. So I started to build the ISP ecosystem in open source. And this is how the idea of Revela ISP started.

I was amazed how good the timing is, with a long queue of image processing patents going through expiration literally right now.

So I implemented essential blocks in numpy, accompanied by the state of the art Hamilton-Adams demosaic, reimplemented in numpy from the expired patents, and I got my basic ISP ready for HW. The first hardware demo runs a simple bilinear demosaic, because in bring-up the simplest block goes first. But Revela is not a basic ISP: the top quality demosaic is already implemented and compiles through the same flow, it is just not first in the hardware queue.

I start with the basics that everybody starts with. But I already carry a long list of blocks and features in my mind, collected over twenty years of working on these things for others. And over time this list will make Revela the best ISP in the world.

It was time to choose the HW. And the problems were already queuing. My plans were to deal with many different sensors and be able to actually handle any required, and no FPGA board solves this well. I looked at where I could source many different sensors, and it turned out to be Raspberry Pi only. All these years different sensor modules were appearing, with one common interface connecting to Raspberry Pi. So the sensor source was found, but how could I connect those sensor modules to an FPGA board, and which one? And yes, there are FPGA boards doing exactly this, they can interface to any of those Raspberry Pi camera sensors. But those boards are really, really expensive. And I know from experience that cost is the main obstacle if you want people to adopt your solutions. Also sensor bring-up, which is a SW problem, would have migrated onto the FPGA board. I wanted pure ISP development with the biggest sensor coverage and minimal problems. I looked at budget FPGA boards capable of ISP and what interfaces they have. And at some moment the crazy idea came to my mind: Raspberry Pi has HDMI and all these FPGAs have HDMI, maybe I could transfer the raw video stream from the sensor through HDMI, and then process it with my ISP like it came from the sensor. And this is how bayerlink was born. This became an amazing setup: a cheap Raspberry Pi with a choice from numerous sensors available, connected through HDMI to numerous budget FPGA boards with HDMI input, ready for Revela ISP.

I purchased a PYNQ-Z2 on eBay, and while it was in the post I implemented picam2hdmi for Raspberry Pi and tested it with some HDMI capture USB dongle I had. I added a web interface to it, so I could do captures and choose the source for streaming, with choosing camera resolution, full frame or cropped, and streaming from a file, so I could replay what I captured or use some generated patterns. And for raw images I used the numpy file format (.npy), so it could be easily produced and consumed.

The board came a couple of days later and the boring time started. I installed Vivado into docker on my Mac and spent lots of days fighting PLLs and other bits and bobs, continuously iterating over the layers of problems. The first achievement was to get HDMI input received and confirmed to be bit identical to the transmitted source. The second goal was to get something visual: my board has a second HDMI, and I specifically bought it so I could use both of them. I connected HDMI out to a TV, and this second stage, getting output there, took much more time, with numerous iterations, each taking twenty minutes of build by Vivado. So my setup got its two ends, bayerlink_in (ready to swap to MIPI, when the time comes) and HDMI out. And the final goal was adding the Revela ISP in the middle. And I finally managed to see the beautiful world around through the Raspberry Pi camera, the bayerlink setup and Revela ISP streaming to my TV. Connecting the Raspberry Pi to the FPGA board through ethernet made it even better: all development goes over WiFi, from a laptop that is not wired to any of it. I pointed the camera at the TV, so through the camera's own preview I could see from anywhere that the picture is really there. I left all this stuff in the other room and was able to do the full development cycle from anywhere, but mostly from the kitchen, as an unlimited source of tea :).

Revela ISP is implemented with single decorated Python function blocks, with blocks having run-time parameters, and a JSON pipeline file defining the connection netlist. Everything else is traced through the code, and the Verilog code is generated through the np2hw compiler. And as the cherry on top I added support for FuseSoC, so the ISP becomes a building block for an ASIC.

Revela is not the first attempt at an open source ISP, and I am glad it is not, it means the need is real. But it is the first where the mathematical model IS the hardware. There is no hand-written Verilog anywhere: the model compiles into Verilog that produces bit exact results, so unlike the others, Revela has no verification problem at all. And verification is the biggest problem that slows hardware development, everyone who shipped RTL knows where the time really goes. For ASICs it matters even more: there a missed bug is not a bad demo, it is a respin. Revela is a fast and robust path to an ASIC. And that is why I added FuseSoC support from the very beginning.

I believe with the growing demand for vision applications, what I am doing will find its users.

This is the start, and I am looking for people who will use what I am building, and who will support it, so we could do great things together.