| Message ID | 20190425125726.16617-1-onemda@gmail.com |
|---|---|
| State | New |
| Headers | show |
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
Paul B Mahol wrote:
>Found 65x65x65 3D LUT in wild
FYI: 128x128x128 3D LUTs do also exist in film production.
Best regards, Reto
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".
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".
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?
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).
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. [...]
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.
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?
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.
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;
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(-)