From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 267464BD06 for ; Sat, 2 Aug 2025 18:03:40 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id EF193687C3F; Sat, 2 Aug 2025 21:03:35 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 81B9668BC73; Sat, 2 Aug 2025 21:03:24 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 572I3NMs017311 ; Sat, 2 Aug 2025 20:03:23 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id A02F82EFE3; Sat, 2 Aug 2025 20:03:23 +0200 (CEST) Date: Sat, 2 Aug 2025 20:03:23 +0200 From: Nicolas George To: tc@ffmpeg.org Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Sat, 02 Aug 2025 20:03:24 +0200 (CEST) Subject: Re: [FFmpeg-devel] The patch series about premultiplied alpha X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Nicolas George (HE12025-08-02): > - The patch series lacks transverse user documentation. > > - The patch series increases the risk of data corruption due to user > negligence and should include at least some guardrails against that. Here is the situation before this patch series: - All alpha is supposed to be straight by default. - A few niche decoders (EXR, JPEG XL) would silently output premultiplied alpha. - A few niche encoders (the same) would silently assume their input is premultiplied alpha. - There is a pair of filters premultiply / unpremultiply. - The overlay filter supports premultiplied alpha if enabled with an undocumented option. - There is no protection at all: if a command connects input with one kind of alpha with out expecting the other kind at any point, it will produce invalid output without so much as a warning. - There is barely any documentation at all. The filters are documented for what they do and that is all. (IIRC, I would have fought the inclusion of the filters, but with Paul one must choose one's battles.) This patch series makes support for premultiplied alpha official. Ideally, official support should include transparent automatic conversion, but that would require too much work. But I think that before inclusion it must fix the two worst problems: - lack of documentation; - risk of creating invalid output without any warning, considering that the work to achieve it is a moderate fraction of the work already invested in the patch series. Documentation is easy: just write a few paragraphs to explain what premultiplied alpha is, where it likely to occur (what did motivate the writing of this series?) and how to deal with it (links to the conversion filters). Protection against creating invalid output, now. As I mentioned above, full negotiation and automatic conversion, which would be ideal, is too much work and therefore too much to ask. Niklas agree on that. On the other hand, protection, i.e. emitting an error and letting the user deal with it, is not much work: - add a flag to filters that support premultiplied input; - add a check for that flag in the framework. In total, maybe two lines in a header, four lines in framework code and one line per filter that will not damage the output. Similar work has already be done for encoders. Such limited work would make the feature much less dangerous for users, it should be done before the feature reaches the public. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".