Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#2847 closed defect (fixed)

3D_LUT_Filter seems to work incorrect

Reported by: rainer fritz Owned by:
Priority: normal Component: avfilter
Version: git-master Keywords: lut3d
Cc: elliottbalsley@gmail.com Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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.

Attachments (3)

ArriAlexaLogCtoRec709.dat (737.0 KB) - added by rainer fritz 6 years ago.
LOG-C to REC709 LUT of Davinci Resolve for ARRI ALexa Prores LOG-C Footage
LUTffmpeg.jpg (51.6 KB) - added by spookybathtub 5 years ago.
scopes of v210 image created by ffmpeg with 3D LUT
LUTresolve.jpg (51.5 KB) - added by spookybathtub 5 years ago.
scopes of YUV 422 10b image created by DaVinci? Resolve with 3D LUT

Download all attachments as: .zip

Change History (22)

Changed 6 years ago by rainer fritz

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

comment:1 Changed 6 years ago by richardpl

  • Reproduced by developer set
  • Status changed from new to open
  • Version changed from 2.0 to git-master

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

comment:2 Changed 6 years ago by 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...

comment:3 follow-up: Changed 6 years ago by richardpl

Than just remove 2 empty lines.

comment:4 in reply to: ↑ 3 Changed 6 years ago by 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...

comment:5 follow-up: Changed 6 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 6 years ago by 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?

comment:7 follow-up: Changed 6 years ago by ubitux

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.

comment:8 in reply to: ↑ 7 Changed 6 years ago by 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...

comment:9 Changed 5 years ago by spookybathtub

  • Cc elliottbalsley@gmail.com added

comment:10 Changed 5 years ago by ubitux

  • Resolution set to fixed
  • Status changed from open to closed

comment:11 Changed 5 years ago by ubitux

  • Keywords lut3d added; 3d lut conversion removed

Changed 5 years ago by spookybathtub

scopes of v210 image created by ffmpeg with 3D LUT

Changed 5 years ago by spookybathtub

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

comment:12 Changed 5 years ago by spookybathtub

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.

comment:13 Changed 5 years ago by ubitux

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?

comment:14 follow-up: Changed 5 years ago by 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?

comment:15 in reply to: ↑ 14 Changed 5 years ago by ubitux

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

comment:16 follow-up: Changed 5 years ago by 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

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

comment:17 in reply to: ↑ 16 Changed 5 years ago by ubitux

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.

Last edited 5 years ago by ubitux (previous) (diff)

comment:18 follow-up: Changed 5 years ago by 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?

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

Last edited 5 years ago by spookybathtub (previous) (diff)

comment:19 in reply to: ↑ 18 Changed 5 years ago by ubitux

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.

Note: See TracTickets for help on using tickets.