[FFmpeg-trac] #3751(undetermined:new): Identity Hald CLUT Introduces Color Shift

FFmpeg trac at avcodec.org
Tue Jul 1 19:47:05 CEST 2014

#3751: Identity Hald CLUT Introduces Color Shift
             Reporter:  aguo         |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |

 I'm having an issue with applying Hald CLUTs to a dpx image sequence.
 I am trying to use ffmpeg to convert a sequence of dpx film scans in
 logarithmic colorspace into two quicktime files: one with h264 encoding
 and one with avid dnxhd encoding.

 In investigating the problems I've been encountering I realized that using
 hald cluts with ffmpeg introduced color shifts that are external to the
 corrections specified by the LUT. Even applying an identity hald clut to
 an image changes the image despite the fact that the identity clut is
 meant to not change the input image at all.

 Our command line/build is:

 C:\Users\aguo>ffmpeg -i
 -i I:\studio\software\release\HaldCLUT\Identity_level_8.HCLUT_neutral.tga
 -filter_complex 'haldclut'

 ffmpeg version N-63548-g6b041cb Copyright (c) 2000-2014 the FFmpeg

 built on May 28 2014 22:01:42 with gcc 4.8.2 (GCC)

 configuration: --enable-gpl --enable-version3 --disable-w32threads

 isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls

 le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-

 e --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug

 libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-

 njpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-

 r --enable-libspeex --enable-libtheora --enable-libtwolame --enable-
 libvidstab -

 -enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-

 --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265

 libxavs --enable-libxvid --enable-decklink --enable-zlib

 libavutil 52. 87.100 / 52. 87.100

 libavcodec 55. 65.100 / 55. 65.100

 libavformat 55. 42.100 / 55. 42.100

 libavdevice 55. 13.101 / 55. 13.101

 libavfilter 4. 5.100 / 4. 5.100

 libswscale 2. 6.100 / 2. 6.100

 libswresample 0. 19.100 / 0. 19.100

 libpostproc 52. 3.100 / 52. 3.100

 The same problem happens when we use a jpg as the input. This should not
 change the input at all but actually ends up introducing a color shift
 that makes the image significantly more blue.

 My guess is that the issue is that ffmpeg is trying to guess/assign a
 colorspace to the Hald CLUT and the colorspace interpretation of the Hald
 CLUT is changing the CLUT.

 As the guy who created CLUTs explains, "A HaldClut is not really an image
 (its only stored in an image file format for convinience), its a lookup

 A lookuptables function is to input some values, in our case a 3
 dimentional value (RGB), and then output some values, again 3 values in
 our case. It doesnt really care where thouse values come from or what they
 mean they just does a conversion. Depending on what you put in the table
 you can make any kind of conversion.

 its just a numbers to numbers conversion"

 If that is the case, is there a way to disable ffmpeg from trying to
 assign the CLUT a colorspace?
 Or if that isn't the issue, why would applying an identity CLUT through
 ffmpeg change in the input image?
 We got the Identity CLUT straight from the developer's website here:

 Any help would be greatly appreciated. Thanks!

Ticket URL: <https://trac.ffmpeg.org/ticket/3751>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list