[FFmpeg-user] convert from bt601 to bt709
gducatel at gmail.com
Mon Jun 16 15:52:02 CEST 2014
Any update regarding this situation, I am still trying to find a proper
command line without success so far.
On Thu, Jun 12, 2014 at 5:46 PM, Rio Kierkels <riokierkels at gmail.com> wrote:
> On 11 June 2014 19:34, Rio Kierkels <riokierkels at gmail.com> wrote:
> > > Except that I was already working in 709 space. Yes the EXR is linear,
> > > and was interpreted as such and converted into 709 and looks correct.
> > >
> > > The DPX on the other hand was tagged as already being 709, yet I had to
> > > manually "undo" the gamma to get it right in 709, which is why it seems
> > > to me like it was applied twice. It should have just come in correct
> > > begin with and look like the EXR snapshot did, if it really was 709.
> > >
> > > Bob
> > This is interesting. It looks to me that your DPX doesn't have a gamma
> > applied at all. But I've only been able to check using ffmpeg's histogram
> > filter that just shows the pixel values without any transforms (right,
> > people with better knowledge about it than I have?). And the lightworks
> > scopes. I'll compare yours and mine on the nuke, flame, smoke and lustre
> > machines tomorrow if I can get some time with them.
> > Rio
> I've confirmed that your DPX doesn't contain a gamma curve by running it
> through both Flame and Nuke. But here is where the fun begins.
> Nuke on output does apply a gamma curve and a BT.709 transformation on the
> primaries however Flame doesn't do anything it seems.
> It just sets some metadata in the DPX headers but doesn't do any transforms
> at all. It is again a difference in implementations.
> So both the DPX sequence I made available and the DPX file rendered by Bob
> are fine in the primaries but you'll have to remember that only
> the sequence contains the gamma curve as per spec. It would be nice if we
> all used the same sequence for testing.
> On 5 June 2014, Gregory Ducatel <gducatel at gmail.com> wrote:
> > Could it be that the color atom are not valid from ffmpeg? Can we set
> > manually?
> > The same quick time file outputed with Nuke, provide a prefered transfer
> > set at 1.8
> > Ffmpeg on the other hand provide a prefered transfer always set at 2.2?
> > Is there a way to change that?
> Actually the Gamma 1.8 setting in nuke is misleading when exporting
> QuickTime files from Nuke.
> If left on that default the gamma correction/handling is done by QuickTime
> So It might not be 1.8 at all depending on QuickTime's handling of things.
> Actually got this from the guy that programmed it when I was on the
> fxphd.com forums ;)
> I didn't have the time to test a working ffmpeg commandline with the DPX
> test sequence today.
> Will do tomorrow. We actually stopped using DNxHD through ffmpeg internally
> in the company because of these inconsistencies...
> C018 4C82 3701 9CAC B723 4C29 2C04 E81A 7418 D158
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
More information about the ffmpeg-user