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.


> 
> 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

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 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"

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to