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 A91AB4AA5A for <ffmpegdev@gitmailbox.com>; Mon, 24 Mar 2025 20:04:58 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D2FD1687BEA; Mon, 24 Mar 2025 22:04:54 +0200 (EET) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C0422687A1B for <ffmpeg-devel@ffmpeg.org>; Mon, 24 Mar 2025 22:04:47 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 1B33E44363 for <ffmpeg-devel@ffmpeg.org>; Mon, 24 Mar 2025 20:04:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1742846687; 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=e/7iffhpm/Yxpsr+0FsRNE76p+8FfhbTZ+yAsIxzS6c=; b=HXM+rplrIPUbKlr+Rym936TOhruP/GX+P835MWfkhd455rDXaxJgXRl29foBsK7J9N1CHy IeBzrheeLE0Ts+1q8Qr8VpJvMgfgt21oE9S7NDaEBfauOwzzj9Ms1eXMkZdxAltirF71Ms BYUwP3LZ+//VGnUeXQ2M+zmxl6Yd4xd4MykZaFzyk7M13QP+0T/D2njoCzLWJ0GaeKESa4 h2AHrXoGnqMQSuSUg+7kZm96F2nRcRW1EwVdV7TS+tWhniOJ+Zq93yJd9eM1pFy7S9Plud IdwEzSyVkSpJJerJrXmVmqtKJzhuOjN0pLeQoEj7eVjlt34XQnatsPa/91N08A== Date: Mon, 24 Mar 2025 21:04:46 +0100 From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Message-ID: <20250324200446.GT4991@pb2> References: <20250324134319.GB1393446@haasn.xyz> MIME-Version: 1.0 In-Reply-To: <20250324134319.GB1393446@haasn.xyz> X-GND-State: clean X-GND-Score: -70 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduiedtieekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfghrlhcuvffnffculdeftddmnecujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefoihgthhgrvghlucfpihgvuggvrhhmrgihvghruceomhhitghhrggvlhesnhhivgguvghrmhgrhigvrhdrtggtqeenucggtffrrghtthgvrhhnpeeigeektdejudffjefhteegjedtgeettefggedthfejgfevhfetgeekjedtvdfhveenucfkphepgedurdeiiedrieejrdduudefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgedurdeiiedrieejrdduudefpdhhvghloheplhhotggrlhhhohhsthdpmhgrihhlfhhrohhmpehmihgthhgrvghlsehnihgvuggvrhhmrgihvghrrdgttgdpnhgspghrtghpthhtohepuddprhgtphhtthhopehffhhmphgvghdquggvvhgvlhesfhhfmhhpvghgrdhorhhg 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="===============6408120423633578917==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org> Archived-At: <https://master.gitmailbox.com/ffmpegdev/20250324200446.GT4991@pb2/> List-Archive: <https://master.gitmailbox.com/ffmpegdev/> List-Post: <mailto:ffmpegdev@gitmailbox.com> --===============6408120423633578917== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pAWnbkjevq6j9SeA" Content-Disposition: inline --pAWnbkjevq6j9SeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Niklas 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 and t= he > need to make a central decision about how to apply rounding and/or dither= ing. >=20 > Some particular cases I want to point out and gather feedback on include: >=20 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? F= or in general, yes [...] >=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 implementations. > But What about SWS_ACCURATE_RND? >=20 > I am thinking that SWS_ACCURATE_RND should essentially be the switch t= hat > 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. >=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 threshold= 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? IMHO in the accurate mode, dither should always be on its also easier to understand 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 may be percievable when contrast, color, resolution or other is changed) thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates --pAWnbkjevq6j9SeA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZ+G62gAKCRBhHseHBAsP q5qtAJ9qEcU90ib+Ah7BS1ekrivAywsEVwCfUISoWzMjkMyZt1Fb2W+S+Ymk+Vw= =UG07 -----END PGP SIGNATURE----- --pAWnbkjevq6j9SeA-- --===============6408120423633578917== 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". --===============6408120423633578917==--