> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Clément Bœsch > Sent: Monday, October 31, 2022 11:57 AM > To: FFmpeg development discussions and patches <ffmpeg- > de...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
