AXIOM Beta UHD Raw Workflow Explained

Color recovery concept from the AXIOM Alpha and the basis for packing raw data inside an RGB image in the AXIOM Beta

For the AXIOM Alpha, we came up with a method to output a color image at 1080p over HDMI from the 4k raw sensor data. We recorded that video feed on an external recorder which defined container and maximum possible resolutions (at the time there were no external UHD capable recorders available yet). With the AXIOM Beta, we maintained this approach but thought about how we could push the boundaries. Currently, with the HDMI plugin module we are limited to 1080p60 as the highest possible throughput mode (It's a frequency limitation of the lanes coming from the Zynq FPGA. A future plugin module with another FPGA onboard featuring gigabit transceivers will be able to output UHD/UK signals directly.). So we thought about methods where we could pack more data into the existing modes and the result is that we can capture 2160p30 inside a 1080p60 (or in the future 2160p25 inside 1080p50 and 2160p24 inside 1080p48) video on an external recorder connected to an AXIOM Beta. So far this mode was called “experimental 4K RAW”, but since it’s getting less and less experimental and we now know it works (we shot the entire April Fools Joke video this way) we actually dropped the “experimental” in the name.

Uncompressed 4K raw still image captured with AXIOM Beta

First Generation Raw Mode

We applied a gamma curve to the 12-bit raw data and directly mapped the Bayer channels to RGB output: R, (G1+G2)*0.45, B. Colors were graded in post production anyway so we didn't care much about the color accuracy on set at the time. However, because of the slight misalignment between the 3 channels, these images contained more resolution information than was needed for 1080p, but less than for UHD. We tried to recover the raw channels without much success, so we ended up attempting to recover a UHD RGB image by solving a modified debayering problem: instead of inputs being [R, G1, G2, B], our inputs were [R, (G1+G2)*0.45, B]. While the results were far from great, this experiment showed where the encoder was struggling, so we knew what to change in the second version.

The main points were:
  • Row/column noise was not corrected, which caused the codec to struggle, introducing very obvious compression artifacts
  • Horizontal resolution was affected because (a) we have averaged the two green channels, and (b) the recorder applied a 422 chroma subsampling, which affected the details in red and blue channels.
  • Output was not covering the full 12-bit range (this was actually the least of our worries)

Second Generation Raw Mode

To solve the downsides from the previous generation, we have implemented the following changes:
  • Recorded the image at double frame rate (1080p60), for the purpose of combining every two HDMI frames into a single UHD frame (3840x2160).
  • To fix the resolution loss in the green channel, we sent the Bayer G1 channel on even frames, and G2 on odd frames.
  • To fix the resolution loss in the red and blue channels, caused by 422 subsampling, we sent the Bayer R/B channels on the even frames from the HDMI stream, and a shifted version (by one pixel) on the odd frames.
  • Subtracted the static components of the row/column noise. Ideally, we should have subtracted a complete dark frame, but this is not yet possible in the current FPGA firmware. Therefore, we have corrected the row/column offsets before sending the data to HDMI (because they were the main reason for the codec struggles), and subtracted the rest of the dark frame from the HDMI image in post-production.
  • To minimize the image alteration caused by encoding the linear 12-bit data as 8-bit, we have designed an optimal LUT (similar to a log gamma), based on the noise profile of the image, that attempts to throw away only bits of noise, without altering the original signal, if possible.
  • In a nutshell, we ended up sending (R,G1,B) on even HDMI frames, and (R’,G2,B’) on odd frames, after applying a LUT. Note: the apostrophe ‘ means “shifted by one pixel”.

The two resolution recovery tricks caused only a tiny (1-pixel) flicker in the preview image on the recorder, which was not noticeable at all in practice. The optimal LUT actually gave a usable preview image - not color correct, but sufficient for monitoring purposes, and containing enough information for recovering the original Bayer raw data almost completely. In other words, not only have we successfully recovered the UHD 12-bit Bayer data from two 1080p 8-bit RGB frames with 4:2:2 chroma subsampling, but we also have the mathematical background for recording linear raw data at lower bit depths, with minimal loss. The optimal LUT for lowering the bit depth can be found from the noise profile of the input image - that is, from the SNR curve. For details on this process, please see our Log Curve Simulation Paper.

Second generation AXIOM Beta raw mode capturing 2160p raw data inside two 1080p frames (A & B) on external recorder

Conversion Process

There are 2 general steps in the process:

Lets say our AXIOM Beta shoot sample clip is called We recorded it on the Shogun so this clip is ProRes compressed.
Converts a video file recorded in AXIOM Beta raw mode to PGM image sequence (recovers the raw data from the compressed movie):
hdmi4k source code on Github

Convert a PGM image sequence to a DNG sequence:
./raw2dng --fixrnt --black=120 clip*.pgm
raw2dng source code on Github
The --fixrnt does temporal row noise correction, and the black level adjustment is needed because the black level from this sensor appears to get lower than the level calibrated with dark frames, and the cause is not yet fully understood (for details see: this wiki page)
Both commands can also be combined to go directly from quicktime mov to DNG sequence:
./hdmi4k INPUT.MOV - | ./raw2dng --fixrnt --pgm --black=120 frame%05d.dng

Read detailed instructions on apertus° wiki

AXIOM Beta UHD raw image as result from combining A & B frames.
Notice the details in the magnified area are almost 100% recovered (compared to the uncompressed raw image).

Resolution Comparison

magnified Frame A, Frame B and the result of recovering raw data from frames A & B

magnified results compared to the golden reference of an uncompressed raw full resolution image
Full resolution chart : uncompressed raw Full resolution chart : experimental raw

AXIOM Beta UHD Sample Clips from April Fools Video

We know that making crazy jokes and producing weird video projects as April Fools Joke is not something one would expect from a camera manufacturer - but remember the AXIOM was born by filmmakers who were fed up with the tools they had to use and so they set out to create their own, so we are still artists at heart. And we were getting impatient already to try out the AXIOM Beta in a real production environment, so April 1st came round and there was our perfect opportunity. This was also the first footage captured outside our lab in UHD raw to test and improve the UHD workflow and gather experience using the Beta in the field in general. The conditions were quite extreme (night shots in the rain with high contrast scenes, green screen keying, etc.) so it was great to see how our image sensor handled these kind of situations and how our image processing can strive to make the most of it.

The following original unprocessed footage downloads provide short sample clips that you can convert to DNG sequences with the above software and scripts yourself. We also provide a DNG for every clip that we converted already for you.
What you see here is still work in progress and will improve and evolve in the future, for example the DNGs don't have white balance metadata and when converting the sample clips the first few frames will have visible row noise.
Calibrated darkframes for AXIOM Beta unit used to shoot the following clips (required for raw conversion): download

Further Links



1 year ago

I do not understand the scripts and commands but I am very, very impressed!!! Keep on fighting for the image!!!

1 year ago

I agree it looks a bit complicated currently but we wanted to share this major achievement at this point none the less - we will try to simplify the workflow in the future. Thanks!

1 year ago
Wayne Morellini

Are these the issues you alluded to. When I originally suggested doing this I also mentioned many other ways to do it, not least treating the combined HDMI sub-streams as a combined data stream, where it did not need to map any pixel to any hdmi pixel, you could just break the raw data bits up however accross the HDMI data components, even non visual bits etc. For the new fpga module combination, you could simply set it in the most data intensive mode possible and break up the data accross all components of the signal. You make up virtual frames and pixels inside the HDMI data without relation to the HDMI frame. Now, even the last HDMI 1.4 can be used to display uhdp60 8 bit 4:2:0 which is enough for a 12 bit raw uhdp60, converting down to raw p50 gives some signaling bits or extra couple of recording bits. If the recorder can handle.these modes. What is the maximum bit depth of a monochrome uhdp50 image (if such a thing is supported). Now, back to this one, by doing these things can you get any extra bandwidth out and recover the green pixels?

But when you get your new FPGA you cpuld consider looking at the above and go HDMI 2a and maybe HDMI 3 (they have to get those 8k images over hdmi somehow).

However, now is the end of the need for HDMI pro recording. Intel Micron Xpoint alternative to flash technology promises much better higher speed recording cheaper. Shortly a thunderbolt x, usb3.x, or latest ssd interface, or card, can be used to record but without viewing functionality. You have control of the design.

1 year ago

Way to go, Axiom team. It is great that you found a solution. I briefly browsed the source for the hdmi4k converter, but by golly, I wasn't able to discern how two 1080p frames can make one 2160p frames. Could you break down the math for me like I'm a first year programming student? Thanks.

1 year ago

I'll write an article about it if people are interested; meanwhile, you can take a look at

There are a few image filters that do the magic - I try to write each Bayer pixel as a linear combination of its RGB neighbours from both A and B frames. That means, the job can be done with simple FIR filter kernels (I tried 3x3 and 5x5), so I solve a linear system to find them from a test image.

There are "only" 4 (Bayer channels) x 3 (RGB) x 2 (A/B) x 2 (odd/even columns) = 48 filter kernels.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.
go back up