Rotate filter to 16-bit per channel image causes false color

[hayamdk]

Summary of the bug:

When rotating 16-bit per channel image false color appears partially.
If I use 8-bit per channel image it is works fine.

How to reproduce:

% ffmpeg -f lavfi -i allrgb -vf format=yuv444p16le,rotate=0.1,format=rgb48 -frames 1 out.tiff
ffmpeg version n5.0.1 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 11.2.0 (Rev10, Built by MSYS2 project)

[Elon Musk]

What means false color here? I do not get this on master version of ffmpeg.

[hayamdk]

Please see the attached file.
Also happened with the version below:

ffmpeg version 2022-05-29-git-a7e0997324-full_build-www.gyan.dev

[Balling]

So you are talking about two diagonal lines then in every square? That does happen.

[hayamdk]

Replying to Balling:

So you are talking about two diagonal lines then in every square? That does happen.

Yes. I'm talking about those two diagonal lines.
Also short blue lines, and false colors at border of squares.

[Elon Musk]

I get none of this, does this happens on windows only?
What you use to render tiff?

[hayamdk]

Replying to Elon Musk:

I get none of this, does this happens on windows only?
What you use to render tiff?

I viewed with GIMP 2.10.24 and MS Paint on Windows.

[Balling]

Replying to Elon Musk:

I get none of this, does this happens on windows only?
What you use to render tiff?

In fact this happens on linux too and in fact the tiff file is bitperfect with windows :) sha256sum of the file itself is D0755FDC28347A1BF7354CFF1276227B82458F5D0B319A1E92784B9331D4D578
and md5 of decoding raw rgb48le is b97e3124afd8ee85202af35833289d63.

Same happens with debian default veiwer.

May be a bug in gcc 11.2.0 and 11.3, that is a buggy piece of 💩💩: ​https://github.com/Beep6581/RawTherapee/issues/6384

Try 12.1 gcc or -fno-tree-loop-vectorize on previous versions.

All tested on ​https://github.com/BtbN/FFmpeg-Builds

[Elon Musk]

Yea, definitely not ffmpeg bug.

md5 of out.tiff as decoded by ffmpeg is:

MD5=1daab09c523548fea9cb74bc36f3d06d

and sha256 of out.tiff is:

bdcfaa18078533f2b96838ccda4e4aeb88e1f6abfb0b016f370c7e81539413a3 out.tiff

Using clang 13 here.

[hayamdk]

Replying to Balling:

I build with gcc 12.1.0 while enabling -fno-tree-loop-vectorize and using legacy march.
But it doesn't fixed.
I'm thinking about trying clang build.

ffmpeg version n5.0.1 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-d3d11va --enable-dxva2 --enable-static --disable-shared --pkg-config-flags=--static --extra-cflags='-I/usr/local/include -fno-tree-loop-vectorize -O2 -march=core2 -static-libgcc -static-libstdc++ -static' --extra-libs=-lpthread --extra-ldflags='-L/usr/local/lib -static' --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-libsoxr --enable-gpl --enable-nonfree

[Balling]

Actually the bug is still there. though md5 for ffmpeg.exe -i out.tiff -f md5 -

is now 350b1dd7cf99db9609e2c2ec3018f9f8 and sha256 is BACBE1D55220F2566B9E0EACBDF5B41ACA3E72FEDD2F24E43624A1538B4A0DB2. In fact there is now additonal bug (the only difference) that black outside the square is not black, but (in hex, R, G, B) 0xdf, 0x0, 0x115. Yep.

You need to open in Yuview .rgb file to see that.

[Balling]

Test on windows. Though on linux it did reproduce too. Can you attach somewhere the file you get? I will compare.

[Michael Koch]

The bug disappears when you switch off interpolation:
rotate=0.1:bilinear=0

See also ticket 9767.

[Michael Koch]

The v360 filter can be used as a workaround. It also has bilinear interpolation by default:

ffmpeg -f lavfi -i allrgb -vf format=yuv444p16le,v360=flat:flat:roll=0.1*-180/PI:ih_fov=45:iv_fov=45:h_fov=45:v_fov=45,format=rgb48 -frames 1 -y out2.tiff

[Michael Koch]

I can reproduce the issue on Windows 10 with this version:

C:\Users\astro\Desktop>ffmpeg -f lavfi -i allrgb -vf format=yuv444p16le,rotate=0.1,format=rgb48 -frames 1 -y out.tiff
ffmpeg version 2022-08-22-git-f23e3ce858-full_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers

built with gcc 12.1.0 (Rev2, Built by MSYS2 project)
configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libjxl --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-liblensfun --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
libavutil 57. 33.101 / 57. 33.101
libavcodec 59. 42.102 / 59. 42.102
libavformat 59. 30.100 / 59. 30.100
libavdevice 59. 8.101 / 59. 8.101
libavfilter 8. 46.103 / 8. 46.103
libswscale 6. 8.103 / 6. 8.103
libswresample 4. 8.100 / 4. 8.100
libpostproc 56. 7.100 / 56. 7.100

Input #0, lavfi, from 'allrgb':

Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Video: wrapped_avframe, rgb24, 4096x4096 [SAR 1:1 DAR 1:1], 25 fps, 25 tbr, 25 tbn

Stream mapping:

Stream #0:0 -> #0:0 (wrapped_avframe (native) -> tiff (native))

Press [q] to stop, ? for help
Output #0, image2, to 'out.tiff':

Metadata:

encoder : Lavf59.30.100

Stream #0:0: Video: tiff, rgb48le(pc, gbr/unknown/unknown, progressive), 4096x4096 [SAR 1:1 DAR 1:1], q=2-31, 200 kb/s, 25 fps, 25 tbn

Metadata:

encoder : Lavc59.42.102 tiff

[image2 @ 00000201dba2c240] The specified filename 'out.tiff' does not contain an image sequence pattern or a pattern is invalid.
[image2 @ 00000201dba2c240] Use a pattern such as %03d for an image sequence or use the -update option (with -frames:v 1 if needed) to write a single image.
frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= 0x
video:99048kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

[Carl Eugen Hoyos]

Please reopen after testing compilation with --disable-optimizations.

[Balling]

Replying to Carl Eugen Hoyos:

Please reopen after testing compilation with --disable-optimizations.

But that is not the default flag.

[Carl Eugen Hoyos]

Definitely not reproducible with all compilers.

[Balling]

Replying to Carl Eugen Hoyos:

Definitely not reproducible with all compilers.

?, so clang is good? Is black color also good on clang?

[Michael Koch]

strong zoom in

[Michael Koch]

When you strongly zoom into the output image, you can see that the vertical tile borders have a nice interpolation, but the interpolation at the horizontal borders is wrong.

[Balling]

Replying to Michael Koch:

When you strongly zoom into the output image, you can see that the vertical tile borders have a nice interpolation, but the interpolation at the horizontal borders is wrong.

Also on your image you can see that black is not longer black, which is a recent regression.

[Michael Koch]

Where can I find documentation for AV_RL16() and AV_WL16()? What are these functions (or macros) doing? I suspect the problem is somewhere in interpolate_bilinear16().

[Balling]

Replying to Michael Koch:

Where can I find documentation for AV_RL16() and AV_WL16()? What are these functions (or macros) doing? I suspect the problem is somewhere in interpolate_bilinear16().

https://ffmpeg.org/doxygen/5.1/intreadwrite_8h.html#aba656beaa26f86d7be6373604a456896

[Carl Eugen Hoyos]

Please test if the following change fixes the issue:

diff --git a/libavfilter/vf_rotate.c b/libavfilter/vf_rotate.c
index 4429e3d543..d319dfe3d9 100644
--- a/libavfilter/vf_rotate.c
+++ b/libavfilter/vf_rotate.c
@@ -269,8 +269,8 @@ static uint8_t *interpolate_bilinear16(uint8_t *dst_color,
         int s01 = AV_RL16(&src[src_linestep * int_x1 + i + src_linesize * int_y ]);
         int s10 = AV_RL16(&src[src_linestep * int_x  + i + src_linesize * int_y1]);
         int s11 = AV_RL16(&src[src_linestep * int_x1 + i + src_linesize * int_y1]);
-        int s0 = (((1<<16) - frac_x)*s00 + frac_x*s01);
-        int s1 = (((1<<16) - frac_x)*s10 + frac_x*s11);
+        int64_t s0 = (((int64_t)(1<<16) - frac_x)*s00 + (int64_t)frac_x*s01);
+        int64_t s1 = (((int64_t)(1<<16) - frac_x)*s10 + (int64_t)frac_x*s11);

         AV_WL16(&dst_color[i], ((int64_t)((1<<16) - frac_y)*s0 + (int64_t)frac_y*s1) >> 32);
     }

[Michael Koch]

That doesn't fix the issue. Tested on Linux.

P.S. I forgot two of the type conversions. Now it works on Linux!
For Windows I can't compile FFmpeg.

[Balling]

Replying to Michael Koch:

That doesn't fix the issue. Tested on Linux.

P.S. I forgot two of the type conversions. Now it works on Linux!
For Windows I can't compile FFmpeg.

I can check windows. Please check on linux that black issue (4 triangles on each side) is fixed too. They must be 0, 0, 0 in 16 bit hex.

[Michael Koch]

Black is 0,0,0

[Balling]

Tested. In fact this patch does not fix wrong black, but other than that it fixes everything. I suppose black is a separate issue, regression.

Black is 0,0,0

Please attach, here is what happens on windows with this patch:

​https://0x0.st/opf6.tiff

(maybe just compare sha256: 039093F5F0B67EC089EC57CFC5B0CB9CE3D656C30C2110F94FFB72851586CEAA).

[Michael Koch]

I use my Linux computer only rarely and did test with an older FFmpeg version. I did verify that the artefacts were visible before I applied the patch, but I didn't check the black level before. Most probably it was already 0,0,0 before I applied the patch.

[Michael Koch]

This version has the correct black 0,0,0:

ffmpeg version 2022-06-16-git-5242ede48d-essentials_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers

built with gcc 11.3.0 (Rev1, Built by MSYS2 project)

This version has wrong black:

ffmpeg version 2022-07-14-git-882aac99d2-essentials_build-www.gyan.dev Copyright (c) 2000-2022 the FFmpeg developers

built with gcc 12.1.0 (Rev2, Built by MSYS2 project)

[Balling]

Yes, as I said, the regression that broke black came after this issue was reported. Bisect someone? Carl? Meanwhile your patch can of course be applied.

[Carl Eugen Hoyos]

Should be fixed in 82479ef6bd107312aa086bab12c29ba4551d544a