hi!
I'm using ffmpeg to convert dpx/exr files to mp4 files.
It seems there's a problem with how ffmpeg compute transformed color values when using .cube lut files, when MAX_DOMAIN is not equal to 1 in the lut file.
In the .cube file specs, MIN_DOMAIN and MAX_DOMAIN refer to input bounds, but it seems that ffmpeg treats them as output bounds.
For example when MAX_DOMAIN = 4, ffmpeg should remap input value in the range [0, 4] to [0, 1] and then perform its lookup, but for now it seems that input value are left unchanged, and output values are remapped to [0, 4], resulting in a super-bright image.
Can anyone help ?
thanks!
.cube lut problem
Re: .cube lut problem
Could you upload your .cube file somewhere?
Re: .cube lut problem
Hello again and thanks for your quick response !
I've tried with the latest nightly, input is now scaled correctly, but seems clamped at some point..
I've uploaded an ACES exr file, a lut, a reference (what it should look like), and ffmpeg current output so that you can see and test yourself.
You can find everything here : https://ufile.io/z4ju36hp
thanks!
I've tried with the latest nightly, input is now scaled correctly, but seems clamped at some point..
I've uploaded an ACES exr file, a lut, a reference (what it should look like), and ffmpeg current output so that you can see and test yourself.
You can find everything here : https://ufile.io/z4ju36hp
thanks!
Re: .cube lut problem
This is both EXR decoder (which does not decode to float) and lut3d filter (which does not work with floats) problem, and is caused by whites/blacks being out of [0 - 1] range.
Re: .cube lut problem
oh ok I understand, so is there a way to pass a "scale" value to the decoder (let's say 0.25) so that exr/dpx/etc files in the range [0, 4] would be scaled to [0, 1] at decode time ?
'