Hi On Mon, Dec 12, 2022 at 08:08:28PM +0000, Drew Dunne wrote: > Previously I sent this patch to solve an overflow in these templates. That > patch wasn't used in favor of one that biased the output calculations to > avoid the double clipping. Now I've found an underflow case, which I've put > the command below, and I'll attach an input image in a reply. > > ./ffmpeg \ > -f rawvideo -video_size 64x64 -pixel_format yuva420p10le \ > -i yuv2rgb_underflow_w64h64.yuva \ > -filter_complex \ > "scale=flags=bicubic+full_chroma_int+full_chroma_inp+bitexact+accurate_rnd:in_color_matrix=bt2020:out_color_matrix=bt2020:in_range=mpeg:out_range=mpeg,format=rgba64[out]" \ > -f rawvideo -codec:v:0 rawvideo -pixel_format rgba64 -map '[out]' \ > -y underflow_w64h64.rgba64 can you trigger a under/overflow with real input ? I mean something where each pixel has a RGB value that can be represented or is close to such value Iam asking because if this never happens with real input then a solution would be to use unsigend ints If this happens with real input values then input values from 0.0 to 1.0 would have to generate a -1.5 or +2.5 on output thats quite a overshoot your example if iam reading it correctly uses white and black pixls with which have chroma values maxed out. but white and black in reality would have all R=G=B and thus no color, the extra cliping takes time and it does not feel like the correct fix for this If someone gives me a pixel that has luma only achievable with R=G=B=0 and then at the same time chroma only achievable with G=R=MAX B=0 or something similar. and then the surrounding pixels also add more overshooting during scaling then iam not sure in which situation the actually color matters because this is not a "real" color That said, if you can make a change that handles such odd fuzzed cases with cliping i dont mind but i think we should not slow down real input for cases that are not as long as we correct all undefined behavior and of course ensure this cannot actually occur with real input Now as you send a 2nd such patch i thought i explain my view a bit better also does this atually trigger under/overflows in all teh chnaged components or just some of teh components ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch