[FFmpeg-devel,1/2] avfilter/vf_lut3d: increase MAX_LEVEL

Submitted by Paul B Mahol on April 25, 2019, 12:57 p.m.

Details

Message ID 20190425125726.16617-1-onemda@gmail.com
State New
Headers show

Commit Message

Paul B Mahol April 25, 2019, 12:57 p.m.
Found 65x65x65 3D LUT in wild

Signed-off-by: Paul B Mahol <onemda@gmail.com>
---
 libavfilter/vf_lut3d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Moritz Barsnick April 25, 2019, 2:19 p.m.
On Thu, Apr 25, 2019 at 14:57:25 +0200, Paul B Mahol wrote:
> Found 65x65x65 3D LUT in wild
[...]
>  /* 3D LUT don't often go up to level 32, but it is common to have a Hald CLUT
>   * of 512x512 (64x64x64) */
> -#define MAX_LEVEL 64
> +#define MAX_LEVEL 65

You may also want to fix the values in the comment right above.

Moritz
Reto Kromer April 25, 2019, 2:28 p.m.
Paul B Mahol wrote:

>Found 65x65x65 3D LUT in wild

FYI: 128x128x128 3D LUTs do also exist in film production.

Best regards, Reto
Paul B Mahol April 25, 2019, 2:46 p.m.
On 4/25/19, Moritz Barsnick <barsnick@gmx.net> wrote:
> On Thu, Apr 25, 2019 at 14:57:25 +0200, Paul B Mahol wrote:
>> Found 65x65x65 3D LUT in wild
> [...]
>>  /* 3D LUT don't often go up to level 32, but it is common to have a Hald
>> CLUT
>>   * of 512x512 (64x64x64) */
>> -#define MAX_LEVEL 64
>> +#define MAX_LEVEL 65
>
> You may also want to fix the values in the comment right above.

Nope. It should stay. Extreme cases are not common.

>
> Moritz
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Paul B Mahol April 25, 2019, 2:47 p.m.
On 4/25/19, Reto Kromer <lists@reto.ch> wrote:
> Paul B Mahol wrote:
>
>>Found 65x65x65 3D LUT in wild
>
> FYI: 128x128x128 3D LUTs do also exist in film production.
>

Thank you, changed locally.

> Best regards, Reto
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Clément Bœsch April 27, 2019, 9:44 a.m.
On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
> On 4/25/19, Reto Kromer <lists@reto.ch> wrote:
> > Paul B Mahol wrote:
> >
> >>Found 65x65x65 3D LUT in wild
> >
> > FYI: 128x128x128 3D LUTs do also exist in film production.
> >
> 
> Thank you, changed locally.

This means one single malloc of 24M unless I'm mistaken. Are we sure
that's what we want?
Paul B Mahol April 27, 2019, 10:29 a.m.
On 4/27/19, Clément Bœsch <u@pkh.me> wrote:
> On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
>> On 4/25/19, Reto Kromer <lists@reto.ch> wrote:
>> > Paul B Mahol wrote:
>> >
>> >>Found 65x65x65 3D LUT in wild
>> >
>> > FYI: 128x128x128 3D LUTs do also exist in film production.
>> >
>>
>> Thank you, changed locally.
>
> This means one single malloc of 24M unless I'm mistaken. Are we sure
> that's what we want?

So you want this to be dynamically allocated? How you want to access elements?
As one big 1d array with size*size*i + size*i + i access or with
casting (which, if works at all
for all compilers is part of C99).
Clément Bœsch April 27, 2019, 11:20 a.m.
On Sat, Apr 27, 2019 at 12:29:44PM +0200, Paul B Mahol wrote:
> On 4/27/19, Clément Bœsch <u@pkh.me> wrote:
> > On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
> >> On 4/25/19, Reto Kromer <lists@reto.ch> wrote:
> >> > Paul B Mahol wrote:
> >> >
> >> >>Found 65x65x65 3D LUT in wild
> >> >
> >> > FYI: 128x128x128 3D LUTs do also exist in film production.
> >> >
> >>
> >> Thank you, changed locally.
> >
> > This means one single malloc of 24M unless I'm mistaken. Are we sure
> > that's what we want?
> 
> So you want this to be dynamically allocated? How you want to access elements?

It is actually already dynamically allocated (the private context is), but
I suppose you meant individual allocs for each dimension. It really is an
open question. Maybe it's not an issue, it's just that I would just think
twice before doing such change because I would assume it would impact
performance on low-end machines due to more sparse memory accesses.

[...]
Paul B Mahol April 27, 2019, 11:29 a.m.
On 4/27/19, Clément Bœsch <u@pkh.me> wrote:
> On Sat, Apr 27, 2019 at 12:29:44PM +0200, Paul B Mahol wrote:
>> On 4/27/19, Clément Bœsch <u@pkh.me> wrote:
>> > On Thu, Apr 25, 2019 at 04:47:00PM +0200, Paul B Mahol wrote:
>> >> On 4/25/19, Reto Kromer <lists@reto.ch> wrote:
>> >> > Paul B Mahol wrote:
>> >> >
>> >> >>Found 65x65x65 3D LUT in wild
>> >> >
>> >> > FYI: 128x128x128 3D LUTs do also exist in film production.
>> >> >
>> >>
>> >> Thank you, changed locally.
>> >
>> > This means one single malloc of 24M unless I'm mistaken. Are we sure
>> > that's what we want?
>>
>> So you want this to be dynamically allocated? How you want to access
>> elements?
>
> It is actually already dynamically allocated (the private context is), but
> I suppose you meant individual allocs for each dimension. It really is an
> open question. Maybe it's not an issue, it's just that I would just think
> twice before doing such change because I would assume it would impact
> performance on low-end machines due to more sparse memory accesses.
>

Considering that some filtergraphs needs 64GB of RAM I consider that non-issue.
Nicolas George April 28, 2019, 9:42 a.m.
Paul B Mahol (12019-04-27):
> Considering that some filtergraphs needs 64GB of RAM I consider that non-issue.

Why was this pushed without leaving Clément time to reply?
Paul B Mahol April 28, 2019, 9:59 a.m.
On 4/28/19, Nicolas George <george@nsup.org> wrote:
> Paul B Mahol (12019-04-27):
>> Considering that some filtergraphs needs 64GB of RAM I consider that
>> non-issue.
>
> Why was this pushed without leaving Clément time to reply?

He replied on IRC.

Patch hide | download patch | download mbox

diff --git a/libavfilter/vf_lut3d.c b/libavfilter/vf_lut3d.c
index 50ea5a8545..d1974b0e05 100644
--- a/libavfilter/vf_lut3d.c
+++ b/libavfilter/vf_lut3d.c
@@ -55,7 +55,7 @@  struct rgbvec {
 
 /* 3D LUT don't often go up to level 32, but it is common to have a Hald CLUT
  * of 512x512 (64x64x64) */
-#define MAX_LEVEL 64
+#define MAX_LEVEL 65
 
 typedef struct LUT3DContext {
     const AVClass *class;