lut3d video filter swaps color channels

[Fred]

In detail:
I compared the colors of the input video with those of the output video. In the output the red channel is displaying the blue input values and the blue channel is displaying the red values.

For example, yellow (green+red) becomes cyan (green+blue) in the output. Objects that where red with a tint of blue are now blue with a tint of red.
Only green objects have kept their color.

This seems to be independent of the LUT file. I tested .cube files generated by:

• Davinci Resolve 9
• Red Giant LUTBuddy
• Briz LUT Converter

They all had the same issue.

Sample command line:
ffmpeg.exe -y -v 9 -loglevel 99 -i lut3d-channel-bug_input-video.avi -vf lut3d=file=lut3d-channel-bug_CineStyle_S-Curve.cube:interp=trilinear -f avi -vcodec libxvid -qscale:v 2 -acodec pcm_s16le -ar 48000 -ac 2 lut3d-channel-bug_output-video.avi

[Carl Eugen Hoyos]

Did you reproduce this with a release or with current git head?

[Fred]

I used the latest zeranoe.com builds of December 22, 2013.
File name: ffmpeg-20131222-git-9b195dd-win32-static.7z

I'm using Windows 7, 32 bit.

[Clément Bœsch]

Can you try this change?

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 79566be..b132865 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -289,11 +289,11 @@ static int parse_cube(AVFilterContext *ctx, FILE *f)
                                 continue;
                             }
                         } while (skip_line(line));
-                        if (sscanf(line, "%f %f %f", &vec->r, &vec->g, &vec->b) != 3)
+                        if (sscanf(line, "%f %f %f", &vec->b, &vec->g, &vec->r) != 3)
                             return AVERROR_INVALIDDATA;
-                        vec->r *= max[0] - min[0];
+                        vec->b *= max[0] - min[0];
                         vec->g *= max[1] - min[1];
-                        vec->b *= max[2] - min[2];
+                        vec->r *= max[2] - min[2];
                     }
                 }
             }

Edit: sorry initial patch was missing the most important change.

[Fred]

Okay, I will try it out. But it will take some time, because I have to check if the MingGW compiler accepts the sources.

[Clément Bœsch]

Replying to FredTester:

Okay, I will try it out. But it will take some time, because I have to check if the MingGW compiler accepts the sources.

I'm asking for a test, because according to ​http://doc.iridas.com/index.php?title=LUT_Formats the value are supposed to be in RGB, and not BGR, so this sounds strange to me.

[Fred]

For testing: Input colors equal output colors

[Clément Bœsch]

While you are at it, can you output that plain.cube in a maximum of other formats? This would be extremely useful.

[Fred]

Ubitux, your diff patch didn't change the problem.

I also verified, that the .cube file loads correctly.

The problem must be somewhere inside the interpolation functions.

To test that, I swapped r and b inside the FILTER define of vf_lut3d.c:

475:    dst[x + b] = av_clip_uint##nbits(vec.r * (float)((1<<nbits) - 1));                      \
476:    dst[x + g] = av_clip_uint##nbits(vec.g * (float)((1<<nbits) - 1));                      \
477:    dst[x + r] = av_clip_uint##nbits(vec.b * (float)((1<<nbits) - 1));                      \

That seems to be nonsense, but with this change the destination frame is correct. This means, that the error must be within the functions called by FILTER.

By the way: I attached a new .cube file, which I built on the Iridas specifications. The color values represent straight lines from 0 to 1, so that the destination frame will be identical to the source frame after the filter is processed.

[Fred]

Yes, I will convert the plain.cube to other formats, too.

[Clément Bœsch]

Replying to FredTester:

Ubitux, your diff patch didn't change the problem.

I updated it a few minutes ago, it should be more correct.

[...]

[Fred]

Another .cube file for testing: it has very low R and very high B values for better identifying the channels (see .png file)

[Fred]

Illustration curves of lowR_normalG_highB.cube

[Fred]

I tested your updated diff patch.

The plain.cube would produce correct colors with the patch, but the lowR_normalG_highB.cube would produce a reddish output, although red must be very low (see the attached lowR_normalG_highB.png which illustrates it).

[Clément Bœsch]

Replying to FredTester:

I tested your updated diff patch.

The plain.cube would produce correct colors with the patch, but the lowR_normalG_highB.cube would produce a reddish output, although red must be very low (see the attached lowR_normalG_highB.png which illustrates it).

Ah interesting. What about this?

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 79566be..d280618 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -273,7 +273,7 @@ static int parse_cube(AVFilterContext *ctx, FILE *f)
             for (k = 0; k < size; k++) {
                 for (j = 0; j < size; j++) {
                     for (i = 0; i < size; i++) {
-                        struct rgbvec *vec = &lut3d->lut[k][j][i];
+                        struct rgbvec *vec = &lut3d->lut[i][j][k];
 
                         do {
                             NEXT_LINE(0);

But in that case, I really would like some tests with the other supposely supported formats. I wrote most parsers with various assumptions, which are probably wrong.

If you want support for other formats, now is the time as well.

[Fred]

It seems to work. Thank you. I applied your second patch, but not the first one.

I will test further, but meanwhile I assembled some LUT test files. They are here:
​http://www.datafilehost.com/d/b9643ffa

There are three parts in the zip file:

• 3 .cube files, that I use for my own programming needs (plain.cube, lowR_normalG_highB.cube, really3D.cube)
• these 3 are converted to other formats using RedGiant LUTBuddy
• then there is a bigger collection of LUT files that I found on the web

And still unexplored are the possibilities of the ARRI LUT Generator
​http://www.arri.com/camera/digital_cameras/tools/lut_generator.html

[Fred]

As of now, all .cube files I was testing are working. Thank you. In my opinion the bug is solved.

By the way: In my problem description I also mentioned files generated by

• Davinci Resolve 9
• Briz LUT Converter

They also work with the patch. You can find them in the zip file under Hook_BMCC_BMDFilm2Vid* If they appear too saturated, that's normal. they are designed to saturate a flat picture style.

[Clément Bœsch]

Fix applied in 307b6b8cb4f8c2e6bd4ecf19395b2f42b929c63c

Thanks for your report, testing, and samples. I haven't the time to check if some other formats are also affected by this bug, but your samples will certainly be useful at some point. Feel free to re-open the ticket if you find another one.