3D_LUT_Filter seems to work incorrect

[rainer fritz]

Summary of the bug:
I'm working a lot with ARRI Alexa LOG-C footage and tried to convert it with the new 3d_lut filter.
The result differs a lot with a file which I converted via Davinci Resolve built in LOG-C to REC709
LUT and one which was downloaded from the ARRI LUT Generator.
The Gamma seems to be ok but the colors seems to be incorrect.

How to reproduce:
I can upload sample files to your ftp where you can try yourself.
Take a LOG-C Alexa Quicktime Prores 4444 file and convert it.

% ffmpeg -i /Volumes/6TB_RAID5/ffmpeg_3DLUT/Source_LOGC_Alexa_trim.mov -s 1920x1080 -vf lut3d="/Volumes/6TB_RAID5/ffmpeg_3DLUT/ArriAlexaLogCtoRec709.dat" -vcodec prores_ks -pix_fmt yuv422p /Volumes/6TB_RAID5/ffmpeg_3DLUT/Alexa_LogC_LUT_converted_ffmpeg.mov

ffmpeg version 2.0
built on Mac OSX 10.8.3

ffmpeg version 2.0 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jul 23 2013 10:30:44 with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-static --disable-shared --enable-postproc --enable-libass --enable-libcelt --enable-libfaac --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-openssl --enable-libtheora --enable-libvo-aacenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid
  libavutil      52. 38.100 / 52. 38.100
  libavcodec     55. 18.102 / 55. 18.102
  libavformat    55. 12.100 / 55. 12.100
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 79.101 /  3. 79.101
  libswscale      2.  3.100 /  2.  3.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  3.100 / 52.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Volumes/6TB_RAID5/ffmpeg_3DLUT/Source_LOGC_Alexa_trim.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2013-08-09 12:49:47
    timecode        : 22:32:19:04
  Duration: 00:00:00.36, start: 0.000000, bitrate: 405676 kb/s
    Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuv444p10le, 2048x1536, 405549 kb/s, SAR 1:1 DAR 4:3, 25 fps, 25 tbr, 25 tbn, 25 tbc
    Metadata:
      creation_time   : 2013-08-09 12:49:47
      handler_name    : Apple Alias-Datensteuerung
    Stream #0:1(eng): Data: none (tmcd / 0x64636D74), 0 kb/s
    Metadata:
      creation_time   : 2013-08-09 12:49:47
      handler_name    : Apple Alias-Datensteuerung
      timecode        : 22:32:19:04
Incompatible pixel format 'yuv422p' for codec 'prores_ks', auto-selecting format 'yuv422p10le'
Output #0, mov, to '/Volumes/6TB_RAID5/ffmpeg_3DLUT/Alexa_LogC_LUT_converted_ffmpeg.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    timecode        : 22:32:19:04
    encoder         : Lavf55.12.100
    Stream #0:0(eng): Video: prores (prores_ks) (apcn / 0x6E637061), yuv422p10le, 1920x1080 [SAR 3:4 DAR 4:3], q=2-31, 200 kb/s, 12800 tbn, 25 tbc
    Metadata:
      creation_time   : 2013-08-09 12:49:47
      handler_name    : Apple Alias-Datensteuerung
Stream mapping:
  Stream #0:0 -> #0:0 (prores -> prores_ks)
Press [q] to stop, [?] for help
frame=    9 fps=2.9 q=0.0 Lsize=    5678kB time=00:00:00.36 bitrate=129214.3kbits/s    
video:5677kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.025735%
k-effectss-MacBook-Pro:~ k-effects$ 

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[rainer fritz]

LOG-C to REC709 LUT of Davinci Resolve for ARRI ALexa Prores LOG-C Footage

[Elon Musk]

If I remove first 3 lines from lut file I get much better result.

[rainer fritz]

If I remove it or set it to 0.0000 i get this error:
[Parsed_lut3d_0 @ 0x7fc271d00000] Unexpected EOF
[AVFilterGraph @ 0x7fc271c147c0] Error initializing filter 'lut3d' with args '/Volumes/6TB_RAID5/ffmpeg_3DLUT/ArriAlexaLogCtoRec709.dat'
Error opening filters!

can you please post the file...

[Elon Musk]

Than just remove 2 empty lines.

[rainer fritz]

Replying to richardpl:

Than just remove 2 empty lines.

I set the first three lines to zero. that worked. but when i remove lines I get an error. result with zeros in the first three lines is still too greenish...

[Elon Musk]

I will repeat once again to remove 2 empty lines, that would be 1st and 3rd.
Why you get error when removing first 3 lines is because 2.0 version is even more picky about syntax.

[rainer fritz]

Replying to richardpl:

I will repeat once again to remove 2 empty lines, that would be 1st and 3rd.
Why you get error when removing first 3 lines is because 2.0 version is even more picky about syntax.

Ok sorry... have it now. But it changes here not the output. It is still the same....
should i upload you a sample file?

[Clément Bœsch]

That format looks "unsupported": the 3DLUTSIZE directive is not supported in the code and likely break the parse_dat() code, because the only .dat sample I had had not those (only tuple values per line). Remove the 3 first lines and it should work.

Also note that there are tons of weird LUT format out there, without any reliable way of probing them. As a result, the parsing, and especially probing of those formats, is pretty weak.

[rainer fritz]

For ARRI Alexa LOG-C Footage you can download and configure your LUTs from their online LUT Generator:
​http://www.arri.com/camera/digital_cameras/tools/lut_generator/lut_generator.html
There you can get all kind of LUT formats...

[Clément Bœsch]

Fixed in 7c3941b25ce0ce74e46658e5e0d36a5ae0a41761.

[Elliott]

scopes of v210 image created by ffmpeg with 3D LUT

[Elliott]

scopes of YUV 422 10b image created by DaVinci Resolve with 3D LUT

[Elliott]

With the recent patch, 3D LUT application is more accurate, but still slightly wrong. I'm comparing against DaVinci Resolve. I start with a ProRes 444 file, apply the same LUT in both tools, and convert to YUV 422 10b (v210). The ffmpeg result is slightly more yellow. Attached are screen grabs of a vectorscope and waveform, which show the difference.

[Clément Bœsch]

Are you sure the problem occurs in lut3d itself and not in the scaling that occurs in different places? FFmpeg will convert from 444 to rgb (probably a 16-bit rgb), then to v210. Make sure this is similar to DaVinci. Also, is that happening also with an identity DaVinci file?

[Elliott]

For reference, I encoded the same 444 file to v210 using both tools, and the results were identical. So that rules out the v210 encoding. It's possible that the problem happens on the RGB conversion. To rule that out , would it make sense to use two format filters in a row, first to rgb48, then to yuv422?

[Clément Bœsch]

Replying to spookybathtub:

For reference, I encoded the same 444 file to v210 using both tools, and the results were identical. So that rules out the v210 encoding. It's possible that the problem happens on the RGB conversion. To rule that out , would it make sense to use two format filters in a row, first to rgb48, then to yuv422?

Maybe try something like -vf format=rgb48,format=yuv422

[Elliott]

Alright, tried that. The RGB conversion is not the problem. The following commands produce identical files, both of which look different than DaVinci's:

ffmpeg -i J001C031_140110_R6MS.mov -an -vcodec v210 -vf "lut3d=file=LogC_to_709.dat" Jv210-LUT.mov
ffmpeg -i J001C031_140110_R6MS.mov -an -vcodec v210 -vf "format=pix_fmts=rgb48le, lut3d=file=LogC_to_709.dat, format=pix_fmts=yuv422p10le" Jv210-rgb-yuv-LUT.mov

One other variable here is that DaVinci works in 32 bit float. Perhaps that accounts for the difference?

[Clément Bœsch]

Replying to spookybathtub:

Alright, tried that. The RGB conversion is not the problem. The following commands produce identical files, both of which look different than DaVinci's:

ffmpeg -i J001C031_140110_R6MS.mov -an -vcodec v210 -vf "lut3d=file=LogC_to_709.dat" Jv210-LUT.mov
ffmpeg -i J001C031_140110_R6MS.mov -an -vcodec v210 -vf "format=pix_fmts=rgb48le, lut3d=file=LogC_to_709.dat, format=pix_fmts=yuv422p10le" Jv210-rgb-yuv-LUT.mov

Is LogC_to_709.dat an identity LUT (no change to the visuals)?

Do some comparison without lut3d at all (or with an identity lut3d, aka no change): just -vf "format=pix_fmts=rgb48le,format=pix_fmts=yuv422p10le"

One other variable here is that DaVinci works in 32 bit float. Perhaps that accounts for the difference?

FFmpeg as well. Interpolation can be different than DaVinci too, see interp option.

[Elliott]

When testing an identity cube LUT today, I got nearly perfect results.
I forgot about the interp option, that's probably a factor too. If I'm not mistaken, the lut3d filter works in rgb48, which is 16 bits/channel. DaVinci works in 32 bits/channel, isn't that a key difference?

Anyway, I've decided it's close enough I'm not going to worry about it.

[Clément Bœsch]

Replying to spookybathtub:

When testing an identity cube LUT today, I got nearly perfect results.
I forgot about the interp option, that's probably a factor too. If I'm not mistaken, the lut3d filter works in rgb48, which is 16 bits/channel. DaVinci works in 32 bits/channel, isn't that a key difference?

It's converted to 32 bits float for interpolation in lut3d. I have no idea what DaVinci is doing, and if it's more correct than what we do.