Re: [FFmpeg-devel] [FFmpeg-cvslog] swscale: use 16-bit intermediate precision for RGB/XYZ conversion

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3159 bytes --]

Hi

On Fri, Mar 14, 2025 at 09:44:22PM +0100, Niklas Haas wrote:
> 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?)

if its one case, would a
if(i == 3415)
    abcd= 12345.98765

fix it ?

do i understand correctly that you want to compute
pow(i / 4095.0, xyzgamma)
or something like that without floats ?

exp(log(i/4095) * xyzgamma)

is a classic one, here you just need a fixed point implemenattion of
log and exp
see log16 and exp16 from tests/tiny_psnr.c, maybe they are neough
or could serve as examples for higher precission ones

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".