avfilter/palette{gen,use}: revert support palettes with alpha

This reverts commit dea673d0d548c864ec85f9260d8900d944ef7a2a.

This change cannot work for several reasons, the most obvious ones are:

- the alpha is being part of the scoring of the color difference, even
  though we can not interpret the alpha as part of the perception of the
  color (we don't even know if it's premultiplied or postmultiplied)
- the colors are averaged with their alpha value which simply cannot
  work

The command proposed in the original thread of the patch actually
produces a completely broken file:

    ffmpeg -y -loglevel verbose -i fate-suite/apng/o_sample.png -filter_complex "split[split1][split2];[split1]palettegen=max_colors=254:use_alpha=1[pal1];[split2][pal1]paletteuse=use_alpha=1" -frames:v 1 out.png

We can see that many color pixels are off, but more importantly some
colors have a random alpha value: https://imgur.com/eFQ2UK7

I don't see any easy fix for this unfortunately, the approach appears to
be flawed by design.

1 files changed, 0 insertions, 8 deletions

diff --git a/doc/filters.texi b/doc/filters.texi
index d0ec0a2181..d5d7ca0197 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -18482,9 +18482,6 @@ Compute new histogram for each frame.
 @end table
 
 Default value is @var{full}.
-@item use_alpha
-Create a palette of colors with alpha components.
-Setting this, will automatically disable 'reserve_transparent'.
 @end table
 
 The filter also exports the frame metadata @code{lavfi.color_quant_ratio}
@@ -18563,11 +18560,6 @@ will be treated as completely opaque, and values below this threshold will be
 treated as completely transparent.
 
 The option must be an integer value in the range [0,255]. Default is @var{128}.
-
-@item use_alpha
-Apply the palette by taking alpha values into account. Only useful with
-palettes that are containing multiple colors with alpha components.
-Setting this will automatically disable 'alpha_treshold'.
 @end table
 
 @subsection Examples