[FFmpeg-devel] [PATCH] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Clément Bœsch
> Sent: Monday, October 31, 2022 11:57 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] Revert
> "avfilter/vf_palette(gen|use): support palettes with alpha"
> 
> On Mon, Oct 31, 2022 at 01:43:11AM +0000, Soft Works wrote:
> [...]
> > > > > The patch I had submitted doesn't change the previous
> behavior
> > > > > without the use_alpha parameter.
> > >
> > > Yes I noticed, but unfortunately I'm reworking the color distance
> to
> > > work
> > > in perceptual color space, and the way that alpha is mixed up in
> the
> > > equation just doesn't make any sense at all and prevents me from
> > > doing
> > > these changes.
> >
> > If you want to implement a new color distance algorithm, it should
> > be either a new filter or a new (switchable) mode for the existing
> > filter.
> 
> Why?
> 
> > Photoshop has these different modes as well and it would
> > surely be useful, but I don't think it should be replacing the
> > existing behavior.
> >
> 
> There is no point in keeping a ton of complexity exposed as user
> options
> for something implementation specific. We offer no guarantee over how
> the
> quantization is expected to run.

Says who?

> > When it turns out that the use_alpha implementation doesn't fit
> > with your new color distance calculation and you add it as
> > an additional mode, then it would be fine IMO when the filter
> > errors in case it would be attempted to use that mode in
> > combination with use_alpha.
> 
> IMO The use_alpha option shouldn't exist in the first place, it
> should be
> the default behaviour because honoring the alpha is the correct thing
> to
> do. That's not what the option is currently doing though.
> 
> > > > Do you think it might make sense to put more weight on the
> > > > alpha value by tripling it? So it would be weighted equally to
> the
> > > > RGB value?
> > >
> > > You cannot mix alpha with colors at all, they are separate
> domains
> > > and you
> > > need to treat them as such.
> >
> > What's interesting is that I've followed the same (simplified)
> > way for adding a use_alpha option to vf_elbg and it provides
> excellent
> > results without treating alpha separately.
> 
> I don't know how the filter works and what it's supposed to do, but
> if
> it's indeed using the same approach as the palette ones, it cannot
> work.

Then it's magic, I guess.
The commands and results are on the same page I have posted.

And pngquant doing the impossible as well:

> Interestingly, pngquant which is supposed to have the best open source
> quantization algorithms seems to be using weights (albeit in a more 
> sophisticated way) and does not handle alpha separately for calculating 
> color distance, variance and averaging:

https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/pam.h#L163-L182 
https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/mediancut.c#L29-L49 
https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/mediancut.c#L449-L476

> That's not how it's going to work, sorry; I'm not going to increase
> complexity and maintenance effort for no gain. Implementing a correct
> support for the alpha will likely involve a revert of that commit
> anyway.

If you want to improve the way it works that's another story.

But at this point, we're talking about removal. And I disagree to that.

Best regards,
softworkz