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]