Opened 5 years ago

Closed 5 years ago

#3236 closed defect (fixed)

lut3d video filter swaps color channels

Reported by: FredTester Owned by:
Priority: normal Component: avfilter
Version: git-master Keywords: lut lut3d
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Attachments (5)

lut3d-channel-bug-ffmpeg.log (8.9 KB) - added by FredTester 5 years ago.
lut3d-channel-bug_CineStyle_S-Curve.cube (772.2 KB) - added by FredTester 5 years ago.
plain.cube (737.0 KB) - added by FredTester 5 years ago.
For testing: Input colors equal output colors
lowR_normalG_highB.cube (737.0 KB) - added by FredTester 5 years ago.
Another .cube file for testing: it has very low R and very high B values for better identifying the channels (see .png file)
lowR_normalG_highB.png (2.9 KB) - added by FredTester 5 years ago.
Illustration curves of lowR_normalG_highB.cube

Change History (20)

Changed 5 years ago by FredTester

Changed 5 years ago by FredTester

comment:1 Changed 5 years ago by cehoyos

  • Keywords lut added

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

comment:2 Changed 5 years ago by FredTester

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.

comment:3 Changed 5 years ago by ubitux

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.

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

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

comment:5 Changed 5 years ago by cehoyos

  • Version changed from 2.1.1 to git-master

comment:6 in reply to: ↑ 4 Changed 5 years ago by ubitux

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.

Changed 5 years ago by FredTester

For testing: Input colors equal output colors

comment:7 Changed 5 years ago by ubitux

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

comment:8 follow-up: Changed 5 years ago by FredTester

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.

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

comment:9 Changed 5 years ago by FredTester

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

comment:10 in reply to: ↑ 8 Changed 5 years ago by ubitux

Replying to FredTester:

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

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

[...]

Changed 5 years ago by FredTester

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

Changed 5 years ago by FredTester

Illustration curves of lowR_normalG_highB.cube

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

comment:12 in reply to: ↑ 11 Changed 5 years ago by ubitux

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.

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

comment:13 Changed 5 years ago by FredTester

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

comment:14 Changed 5 years ago by FredTester

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.

comment:15 Changed 5 years ago by ubitux

  • Keywords lut3d added
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.