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 7FFB84BAD1 for <ffmpegdev@gitmailbox.com>; Fri, 28 Mar 2025 20:08:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7F7A1687C3F; Fri, 28 Mar 2025 22:08:43 +0200 (EET) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 80CAE68097C for <ffmpeg-devel@ffmpeg.org>; Fri, 28 Mar 2025 22:08:36 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 7577F43226 for <ffmpeg-devel@ffmpeg.org>; Fri, 28 Mar 2025 20:08:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1743192515; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YNN+oU2m1Wyxah1Af9q/fVd+kUVDe6GHhy9B1Hw4zbU=; b=gt9F8oN9v00EQxWQKmzkzpuOgg5/mV07xVlXrbMHh87XOJJm4S5oH+y6cOZy2c2oqAGQ0n 9o4TAmQS3wDc6xjdm9TTssXulmLhTT8W0AxljEIhXLSl17gawW1+bX4Rb5foMU3c7T1bBT EaWe13P+Y7ktL7p2xbZAc8Qhb9slb0aau/+bK2oJECCn9tGZLotocHyCKflI5aG8T7xnQD U11vVQXkL0MgxxEb11o5liBXygR6E1qQCevrMilkBeKIIOthgqZHP98Js4lMPC4lV7Grkw L75E0eSfLRBSZQx5tXcjigWvqSrVLCMY494OKH1lw0R4rNNv6o+gM2rhFFwk9Q== Date: Fri, 28 Mar 2025 21:08:34 +0100 From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Message-ID: <20250328200834.GG4991@pb2> References: <20250324134319.GB1393446@haasn.xyz> <20250324200446.GT4991@pb2> <20250325025925.GB1438997@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20250325025925.GB1438997@haasn.xyz> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddujedvvdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeeigeektdejudffjefhteegjedtgeettefggedthfejgfevhfetgeekjedtvdfhveenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg X-GND-Sasl: michael@niedermayer.cc 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: multipart/mixed; boundary="===============6566441234941078840==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250328200834.GG4991@pb2/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> --===============6566441234941078840== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wkojmuY/AfMRTX7Y" Content-Disposition: inline --wkojmuY/AfMRTX7Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 25, 2025 at 02:59:25AM +0100, Niklas Haas wrote: > On Mon, 24 Mar 2025 21:04:46 +0100 Michael Niedermayer <michael@niedermay= er.cc> wrote: > > Hi Niklas > >=20 > > On Mon, Mar 24, 2025 at 01:43:19PM +0100, Niklas Haas wrote: > > > Hi all, > > >=20 > > > As part of my ongoing swscale rewrite, we have both the opportunity a= nd the > > > need to make a central decision about how to apply rounding and/or di= thering. > > >=20 > > > Some particular cases I want to point out and gather feedback on incl= ude: > > >=20 > >=20 > > all IMHO: > >=20 > >=20 > > > 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 > >=20 > > by default, yes > >=20 > >=20 > > [...] > >=20 > > > 2. At what bit depth does dithering become negligible? For context, t= he > >=20 > > I think we should consistently always apply it by default > >=20 > > also especially if someone does work with lets say 32bit, that person h= as > > some strange requirements already and direct human vison may not be it. > >=20 > >=20 > > [...] > >=20 > > > 3. Should we dither per-channel after conversion from grayscale to RG= B? For > >=20 > > in general, yes > >=20 > >=20 > > [...] > > >=20 > > > 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 implementat= ions. > > > But What about SWS_ACCURATE_RND? > > >=20 > > > I am thinking that SWS_ACCURATE_RND should essentially be the swit= ch that > > > toggles our preferred resolution of question 1. So in other words,= with > > > SWS_ACCURATE_RND specified, full range upconversions should go thr= ough an > > > accurate dither pass, while being relaxed to the simple (x << 2) |= (x >> 6) > > > upconversion in the absence of this flag. > > >=20 > > > 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 thres= hold as > > > appropriate for the content type. > > >=20 > > > This would lead to the following conversions, as an illustration: > > >=20 > > > SWS_ACCURATE_RND specified: > > >=20 > > > - 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 > > >=20 > > > SWS_ACCURATE_RND absent: > > >=20 > > > - 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 > > >=20 > > > Does this seem reasonable? > >=20 > > IMHO in the accurate mode, dither should always be on > > its also easier to understand >=20 > That seems reasonable. It does mean some conversions are necessarily going > to get slower than the status quo. >=20 > >=20 > > but there could be a flag for vissual percetion > >=20 > > 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 >=20 > This could be the behavior of SWS_DITHER_AUTO, which is not clearly defin= ed > either way. >=20 > In a much earlier thread we discussed the idea of adding quality "presets= ", > which seems like a good thing to consider as well. >=20 > How about this proposal? >=20 > 1. SWS_ACCURATE_RND is added to the default flags. > 2. When SWS_ACCURATE_RND is absent, the implementation may truncate inste= ad > of rounding; to enable e.g. fast alpha upconversions. > 3. SWS_DITHER_AUTO implies dithering only when the result is visually nee= ded, > and skips dithering otherwise > 4. When a specific dither mode is requested, dithering is always performe= d, > at whatever bit depth. sure, sounds reasonable and simple to understand thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato --wkojmuY/AfMRTX7Y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ+cBvAAKCRBhHseHBAsP q4wTAJ9TxXExsky3WpSB6LAZe6x/ymThkACfdaxITah7d8WlcllgbUL3QKQPWF8= =Za+N -----END PGP SIGNATURE----- --wkojmuY/AfMRTX7Y-- --===============6566441234941078840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============6566441234941078840==--