[FFmpeg-devel] Re: [PATCH] lavfi: protection against premultiplied alpha (was: The patch series about premultiplied alpha)

[Nicolas George via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

Sorry, it has been very busy weeks at work. I will have to be terse.

Niklas Haas via ffmpeg-devel (HE12025-08-22):
> Filters which do not touch the alpha channel, overwhelmingly either do not
> even care about the pixel contents, or produce their desired effect
> *regardless* of the colorspace.

I have already granted you that filters that do not consider pixel
values are not affected.

You have not acknowledged that they are a minority.

> What about frames in a perceptually uniform colorspace (like ICtCp)? Should
> we block filters from accepting anything by default except linear light
> floating point RGB?

If we want to do things properly, then yes, we should apply the same
care for these cases.

But you neglect that all these other color spaces preserve the
orthogonality between color and alpha. Only premultiplied alpha breaks
that.

> Dude, I understand the theory of colorspaces probably better than anybody
> else in this project.

Show, don't tell.

> The matter of fact is, that filtering in straight alpha actually overwhelmingly
> produces *wrong* results in practice.

This is a separate issue.

> I mean, if you see another filter that produces obviously broken results
> with premultiplied alpha, feel free to point it out, and I will probably
> get around to fixing it at some point. (Or fix it yourself - as you can see
> from the example of drawutils, the fix is usually trivial)

I can identify quite a few of them just by looking at the list.

“Fixing” them would be a waste of time.

> The fact that the blacklist is nonempty, obviously does not on its own
> constitute an argument for why a whitelist should therefore be the preferred
> solution.

The fact that the blacklist is still nonempty when you think you have
fixed everything is a proof that you are underestimating the problem.

What makes a whitelist the only acceptable solution is another reason,
though: the consequences of getting it wrong. If a filter is wrongly
assumed to work, it produces garbage that gets written to the output of
the users. If a filter is wrongly assumed to not work, the system will
just insert conversion filters and waste a few cycles.

One is unacceptable, the other is negligible. The default should be to
choose the issue with negligible drawbacks.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org