From: Niklas Haas <ffmpeg@haasn.xyz> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] swscale: use 16-bit intermediate precision for RGB/XYZ conversion Date: Fri, 14 Mar 2025 21:44:22 +0100 Message-ID: <20250314214422.GB518999@haasn.xyz> (raw) In-Reply-To: <20250314010930.GB892569@haasn.xyz> On Fri, 14 Mar 2025 01:09:30 +0100 Niklas Haas <ffmpeg@haasn.xyz> wrote: > On Fri, 14 Mar 2025 00:54:25 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote: > > Hi > > > > On Sun, Jan 26, 2025 at 07:26:59PM +0100, Michael Niedermayer wrote: > > > On Thu, Dec 26, 2024 at 07:33:23PM +0000, Niklas Haas wrote: > > > > ffmpeg | branch: master | Niklas Haas <git@haasn.dev> | Mon Dec 16 14:49:39 2024 +0100| [af6d52eec66961f6a502b0f2f390c12226d087cd] | committer: Niklas Haas > > > > > > > > swscale: use 16-bit intermediate precision for RGB/XYZ conversion > > > > > > > > The current logic uses 12-bit linear light math, which is woefully insufficient > > > > and leads to nasty postarization artifacts. This patch simply switches the > > > > internal logic to 16-bit precision. > > > > > > > > This raises the memory requirement of these tables from 32 kB to 272 kB. > > > > > > > > All relevant FATE tests updated for improved accuracy. > > > > > > > > Fixes: #4829 > > > > Signed-off-by: Niklas Haas <git@haasn.dev> > > > > Sponsored-by: Sovereign Tech Fund > > > > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=af6d52eec66961f6a502b0f2f390c12226d087cd > > > > --- > > > > > > this breaks on x86-32 > > > > ping > > > > the fate tests for a major architecture are broken since this > > This impacts future bisections over that range for example > > My bad, missed this email for some reason. > > Will investigate and fix tomorrow. So, I found the bug, but I don't know how to fix it properly. The problem is that tha XYZ/RGB conversion tables are calculated using excess precision from the x87 FPU. This results in slightly different rounding behavior in exactly one case (i == 3415). Fixing this requires setting -mfpmath=sse at compile time. Strangely, I was not able to force the compiler to discard the excess precision even with forcing -fexcess-precision=standard and storing every single subexpression to a `volatile double`. How do we deal with such cases generally? I can think of several options, such as hard-coding the table values (unappealing), or somehow using integer math (very unappealing, how do we calculate an integer power without massive loss of precision?) > > > > > you can trivially test this on x86-64 with something like: > > --cross-prefix=/usr/i686-linux-gnu/bin/ --cc='ccache i686-linux-gnu-gcc-7' --arch=x86_32 --target-os=linux --enable-cross-compile > > if you have the correponding packages installed > > > > before af6d52eec66961f6a502b0f2f390c12226d087cd > > TEST filter-pixdesc-xyz12be > > > > after af6d52eec66961f6a502b0f2f390c12226d087cd: > > --- src/tests/ref/fate/filter-pixdesc-xyz12be 2025-03-14 00:46:40.445681223 +0100 > > +++ tests/data/fate/filter-pixdesc-xyz12be 2025-03-14 00:47:08.301903796 +0100 > > @@ -1 +1 @@ > > -pixdesc-xyz12be 1508a33dea936c45d9ee13f7743af00d > > +pixdesc-xyz12be 198f43f452bc55f4ca1e0e0171de5c4c > > Test filter-pixdesc-xyz12be failed. Look at tests/data/fate/filter-pixdesc-xyz12be.err for details. > > make: *** [src/tests/Makefile:311: fate-filter-pixdesc-xyz12be] Error 1 > > > > in master: > > --- src/tests/ref/fate/filter-pixdesc-xyz12be 2025-03-14 00:46:40.445681223 +0100 > > +++ tests/data/fate/filter-pixdesc-xyz12be 2025-03-14 00:48:43.042660972 +0100 > > @@ -1 +1 @@ > > -pixdesc-xyz12be 1508a33dea936c45d9ee13f7743af00d > > +pixdesc-xyz12be 198f43f452bc55f4ca1e0e0171de5c4c > > Test filter-pixdesc-xyz12be failed. Look at tests/data/fate/filter-pixdesc-xyz12be.err for details. > > make: *** [src/tests/Makefile:315: fate-filter-pixdesc-xyz12be] Error 1 > > > > > > thx > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > Never trust a computer, one day, it may think you are the virus. -- Compn _______________________________________________ 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".
prev parent reply other threads:[~2025-03-14 20:44 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20241226193325.288834126EE@natalya.videolan.org> 2025-01-26 18:26 ` Michael Niedermayer 2025-03-13 23:54 ` Michael Niedermayer 2025-03-13 23:58 ` Michael Niedermayer 2025-03-14 0:09 ` Niklas Haas 2025-03-14 20:44 ` Niklas Haas [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20250314214422.GB518999@haasn.xyz \ --to=ffmpeg@haasn.xyz \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git