From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ffmpeg-devel-bounces@ffmpeg.org> Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 626E74ABA6 for <ffmpegdev@gitmailbox.com>; Tue, 25 Mar 2025 01:59:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F00246807E6; Tue, 25 Mar 2025 03:59:32 +0200 (EET) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2CC7C6807E6 for <ffmpeg-devel@ffmpeg.org>; Tue, 25 Mar 2025 03:59:26 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1742867965; bh=AE3dOYaQvvoh4HUAk7FeqeHIRRk6A/vJGgP4odjUIvQ=; h=Date:From:To:Subject:In-Reply-To:References:From; b=GM0IWawFHTlGk2bV34BoSnkQCjgbBuctxUw0LhHxIAEsdQX4esUMwS5qXuVLBuoBg HgQdGRvn5JSWY0fjPVPta0kqd+ECtDPpt58EqFpd6MtLGMWQkLvEREZUTl61aRMlSN PQ4XGHMQ8JvhgmfCGeOkEeiuNkpL4tp6p7Ug52zw= Received: from localhost (unknown [185.35.208.89]) by haasn.dev (Postfix) with UTF8SMTPSA id D509140717 for <ffmpeg-devel@ffmpeg.org>; Tue, 25 Mar 2025 02:59:25 +0100 (CET) Date: Tue, 25 Mar 2025 02:59:25 +0100 Message-ID: <20250325025925.GB1438997@haasn.xyz> From: Niklas Haas <ffmpeg@haasn.xyz> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> In-Reply-To: <20250324200446.GT4991@pb2> References: <20250324134319.GB1393446@haasn.xyz> <20250324200446.GT4991@pb2> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] [RFC] swscale dithering X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org> List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe> List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel> List-Post: <mailto:ffmpeg-devel@ffmpeg.org> List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help> List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>, <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe> Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250325025925.GB1438997@haasn.xyz/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> On Mon, 24 Mar 2025 21:04:46 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote: > Hi Niklas > > On Mon, Mar 24, 2025 at 01:43:19PM +0100, Niklas Haas wrote: > > Hi all, > > > > As part of my ongoing swscale rewrite, we have both the opportunity and the > > need to make a central decision about how to apply rounding and/or dithering. > > > > Some particular cases I want to point out and gather feedback on include: > > > > all IMHO: > > > > 1. Should we dither and/or accurately round when scaling up full range > > content? For example, say you are converting from full-range rgb24 to > > by default, yes > > > [...] > > > 2. At what bit depth does dithering become negligible? For context, the > > I think we should consistently always apply it by default > > also especially if someone does work with lets say 32bit, that person has > some strange requirements already and direct human vison may not be it. > > > [...] > > > 3. Should we dither per-channel after conversion from grayscale to RGB? For > > in general, yes > > > [...] > > > > 3. What should we make of the SWS_ACCURATE_RND and SWS_BITEXACT flags? I am > > personally thinking that SWS_BITEXACT should become a no-op flag, with > > bit exact output being the default behavior of all new implementations. > > But What about SWS_ACCURATE_RND? > > > > I am thinking that SWS_ACCURATE_RND should essentially be the switch that > > toggles our preferred resolution of question 1. So in other words, with > > SWS_ACCURATE_RND specified, full range upconversions should go through an > > accurate dither pass, while being relaxed to the simple (x << 2) | (x >> 6) > > upconversion in the absence of this flag. > > > > How should this flag relate to question 2? With the flag specified, I am > > thinking that we should also force dithering even at 16 bit depth, and > > skip dithering in this case only in the flag's absence. If so, what > > bit depth should the cutoff threshold be, for when to skip accurate > > dithering? I am thinking to simply use the 12/14 bit SDR/HDR threshold as > > appropriate for the content type. > > > > This would lead to the following conversions, as an illustration: > > > > SWS_ACCURATE_RND specified: > > > > - rgb24 -> yuv420p10: full dithering > > - rgb24 -> yuv420p12: full dithering > > - rgb24 -> rgb30: full dithering > > - rgb24 -> rgba64: full dithering > > - yuva444p -> yuva444p10: scale YUV, dither alpha > > - yuva444p14 -> yuva444p16: scale YUV, dither alpha > > - yuv444p10 -> yuv444p14: left shift, no dithering needed > > > > SWS_ACCURATE_RND absent: > > > > - rgb24 -> yuv420p10: full dithering > > - rgb24 -> yuv420p12: truncate if SDR, full dithering if HDR > > - rgb24 -> rgb30: truncate > > - rgb24 -> rgba64: truncate > > - yuva444p -> yuva444p10: left shift YUV, truncate alpha > > - yuva444p14 -> yuva444p16: left shift YUV, truncate alpha > > > > Does this seem reasonable? > > IMHO in the accurate mode, dither should always be on > its also easier to understand That seems reasonable. It does mean some conversions are necessarily going to get slower than the status quo. > > but there could be a flag for vissual percetion > > SWS_VISSUAL_PERCEPTION (or some better name) > some flag that uses less accurate and faster operations when their > effect is expected to be vissually impercivable This could be the behavior of SWS_DITHER_AUTO, which is not clearly defined either way. In a much earlier thread we discussed the idea of adding quality "presets", which seems like a good thing to consider as well. How about this proposal? 1. SWS_ACCURATE_RND is added to the default flags. 2. When SWS_ACCURATE_RND is absent, the implementation may truncate instead of rounding; to enable e.g. fast alpha upconversions. 3. SWS_DITHER_AUTO implies dithering only when the result is visually needed, and skips dithering otherwise 4. When a specific dither mode is requested, dithering is always performed, at whatever bit depth. Tying this into the quality presets, I suggest the "default" quality prefix imply (accurate_rnd + dither=auto). One of the "slower" presets could always enable dithering, while one of the "faster" presets could skip accurate rounding. > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have often repented speaking, but never of holding my tongue. > -- Xenocrates > _______________________________________________ > 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". _______________________________________________ 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".