On 18/03/2026 14:04, Michael Niedermayer via ffmpeg-devel wrote:
Hi Lynne
On Wed, Mar 18, 2026 at 06:06:22AM +0100, Lynne via ffmpeg-devel wrote:
On 18/03/2026 01:11, Michael Niedermayer via ffmpeg-devel wrote:
[...]
[...]
when it comes to Decorrelating, the proposed filters are asymetric,
how would symmetric ones perform ? and how do adaptive ones perform?
The current implementation does not prohibit adaptive decorrelation. The RCT
search can still be performed to find more optimal coefficients than (1, 1).
While it can be extended with more expensive search, I think that extending
the decorrelation process should be done in a way in which RGBA coding would
also benefit, than tuning it specifically for Bayer. Perhaps that's
something we can investigate in the future, since custom RCT coefficients
are still marked as unstable.
G B G B G B G B
R G R G R G R G
G B G B G B G B
R G R G R G R G
G B G B G B G B
each blue and red sample has 4 adjacent green samples
That is each sample can be decorrelated with an average of 4, 3, 2 or 1
of these samples. Thats without considering more distant samples.
(this could be attempted in a local edge direction dependant way)
PR22528 uses the left and top green samples for blue and the bottom and right
green
samples for red.
Such a asymetric fixed choice "feels" strange
The PR is implemented for RGGB16 (R G\n G B), not GBRG16.
The pattern we get is:
R G R G R G R G
G B G B G B G B
R G R G R G R G
G B G B G B G B
R G R G R G R G
G B G B G B G B
The names we use for the samples should have also been a hint.
My text and analysis refers to RGGB.
If the CFA example starts at a even or odd line is something i did not
pay attention to
Also you effectively use a haar transform to split the green into 2 green planes
why that and not the 5/3 one from j2k. But either feels odd, putting a wavelet
style transform into ffv1 feels odd.
I really would like to see some numbers that show that this is the best choice
5/3 is a Wavelet transform that requires 6 samples in both directions, and
would impose a restriction on the slice width and height. Haar can operate
on just a single Bayer quad.
you can apply a 5/3 transform on a 1x1 image or a 2x2 image, if thats what you
want to do.
You could zero-pad the data, but then you're essentially not far off
from what Haar does by interpolating, but with an offset basis. Is this
what you were referring to?
I could have extended the RCT by adding a parameter to bias the split,
however the 2 green samples in each quad are already highly correlated,
since they are adjacent.
The question is not, if they are adjacent.
They are adjacent in a plain RGB image too. And we dont do this diagonal haar
split when storing plain RGB images.
And the reason why we dont do it is.
1. we never tested it
2. if we would test it we would VERY likely find out it worsens compression
Yes, I agree with that.
And this is the core problem here.
We need to know what these different choices do to compression (and speed),
to be able to make a choice
We also need the "state of teh art CFA compression algorithms" (only
decorrelation
and teh full ones or whatever part we can use) compared
And then make a choice what we should use.
To me this looks a bit like "heres my favorite algorithm, take it"
I performed literature review, provided references, as well as a review
of existing codecs, and weighted in feasibility of approaches to arrive
at this proposal.
I much more would liek to see "heres the compression my PR achieves, heres the
compression it achieves when this and that is changed, heres the compression
the best state of the art alternatives achieve"
What I was hoping for is feedback about whether this path - e.g.
modelling Bayer coding from the RGB path, including a decorrelation
filter like RCT - is agreeable. We have an existing codec, and while we
could invent a completely new coding scheme for Bayer, I think that
making it fit in is conceptually what makes sense.
I will prepare performance and compression figures too, of course.
You are mainly focusing on the use of Haar to decompose Bayer into
median + difference for the green samples. Would you prefer a more
general interpolation or predictor instead? Like I mentioned, I wouldn't
mind this, though it would be better if it benefitted RGB coding as well.
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
