On 17/03/2026 14:54, Michael Niedermayer via ffmpeg-devel wrote:
Hi everyone

STF is funding FFv1 Bayer video support.

The FFv1 specification has no Bayer support, so obviously part of this task
has to be to design the bitstream and compression algorithm and or how to
map bayer onto existing non bayer FFv1.

If you know an algorithm that should be considered, then please reply

Similarly if you know research work that compares bayer compression technologies
please reply too

I wrote the proposal.

In my research, I compared several other existing algorithms, and I think this is by far the most advanced compression for Bayer data someone's written.
All other lossless algorithms prioritize speed over compression.

- Redcode RAW (R3D, what RED cameras use, non-public) is based on Haar wavelets, with no decorrelation, since it has to be done in-camera. It only relies on Golomb codes.

- JPEG2000 supports lossless Bayer, but similar to R3D, does no prediction at all. It relies on the bitplane entropy coding to save bits.

- RawZipper is the only specialized codec for lossless Bayer data out there. It isn't public, but all it does is it wraps Lossless JPEG JPEG2000/JPEG-XL, and applies compression independently to each component individually, doing zero decorrelation.

The reason for the small amount of codecs is that RED has a patent on in-camera lossless Bayer compression, and they're very actively defending it (even though theirs is based on 30 year old tech). This has had a freezing effect on codec development.

This will be the first new codec specifically designed for Bayer data storage.

So I based this on the best lossy variant, which was Blackmagic RAW. It does a partial debayering, but here, I keep the difference instead of throwing it away. Then I use the regular FFv1 prediction scheme to encode it. The prior art for the decomposition is "Reversible color transform for Bayer color filter array images" by Iwahashi et. al.

I don't really see too many ways this can be improved. Decorrelating the 2 green channels is already pretty optimal. Possibly using 3 contexts instead of 2 may help, since the post-RCT green difference could pollute the first context, but this would only matter for level 4's inter-frame coding (disabled by default), and would make intra-only suboptimal (reusing the first context whenever possible is always a plus).

Performance-wise, this is roughly equivalent to FFv1 encoding quarter resolution GBRAP16, due to pixel data in Bayer being considerably less dense.

This compression method can be implemented in existing implementations, as well as in hardware implementations, such as the Vulkan FFv1 encoder and decoders.
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to