convert from bt601 to bt709

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
On 6/10/2014 4:52 PM, Carl Eugen Hoyos wrote:

> Just to make sure we understand each other:
> Did you test the command lines I provided?
> Or did you test them, found out that they
> don't work and improved them?

Never mind, I was not originally understanding your workaround.  I see
now you meant to do 2 encodes, a first pass to rawvideo with yuvj422p
and then from that to the destination format (DNxHD or whatnot) while
lying to ffmpeg about the input pixel format being yuv422p instead of
yuvj422p, which makes sense.

Bob
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Carl Eugen Hoyos
Bob Maple <bobm-ffmpeg <at> burner.com> writes:

> I see now you meant to do 2 encodes, a first pass
> to rawvideo with yuvj422p and then from that to the
> destination format (DNxHD or whatnot) while lying
> to ffmpeg about the input pixel format being
> yuv422p instead of yuvj422p, which makes sense.

Does it work?

You can use a pipe to avoid the (large) intermediate
file, this should not have a significant performance
hit.

Carl Eugen

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
On 6/11/2014 1:04 AM, Carl Eugen Hoyos wrote:

> Does it work?

Yes.  Although going 10bit -> 8bit is a little noisy, seems to introduce
some 'striping' where every other pixel has a value +1 even though all
of the input pixels are exactly the same.  Rounding errors I suppose but
I don't know that I understand why.

I'm trying to start learning the source but it's doing my head in :)

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
In reply to this post by Bob Maple
Here's also a capture of my scope from the DPX sequence and of the EXR.

>  You can see the arc in the ramp on the DPX, the elevated chroma levels,
> etc.
>
> DPX Imported: http://clients.idolum.com/get/6714cf583c5b
> EXR Imported: http://clients.idolum.com/get/08f993a4c57c
>

Both of these seem to me to be correct. The EXR is rendered linearly so
without a power curve and using linear-light RGB tristimulus values.
The DPX is rendered from those values to BT.709 primaries and a BT.1886
powerfunction creating that curve along the greyscale ramp so we get R'G'B'
in BT.709.
Which is what we are going for right? Or are we aiming for linear RGB with
no powerfunction?


> It seems like maybe the DPX is either tagged wrong, or some operation
> happened twice.  If I apply a 'Remove Rec709 Transform' LUT to the DPX,
> it winds up correct.
>

This makes sense as it will do an inverse powerfunction on the image
leading to a linear waveform readout but an incorrect image as your monitor
will do that inverse powerfunction again.
However you should also see your primaries leave the squares and shift back
to the center in your vectorscope if the LUT is a true inverse of BT.709.

I've just did an export on one of our flames from the EXR like you did with
the standard DPX 10bit presets and it also doesn't apply a gamma curve,
which puzzles me.

It just could be me not understanding the BT.709/BT.1886 HD spec.

--
C018 4C82 3701 9CAC B723  4C29 2C04 E81A 7418 D158
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Bob Maple
On 6/11/2014 2:58 AM, Rio Kierkels wrote:

> Both of these seem to me to be correct. The EXR is rendered linearly so
> without a power curve and using linear-light RGB tristimulus values.

 [...]

>> It seems like maybe the DPX is either tagged wrong, or some operation
>> happened twice.  If I apply a 'Remove Rec709 Transform' LUT to the DPX,
>> it winds up correct.

> This makes sense as it will do an inverse powerfunction on the image
> leading to a linear waveform readout but an incorrect image as your monitor
> will do that inverse powerfunction again.

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 to
begin with and look like the EXR snapshot did, if it really was 709.

Bob
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
> 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 to
> 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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Rio Kierkels
On 11 June 2014 19:34, Rio Kierkels <[hidden email]> 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 to
> > 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 <[hidden email]> wrote:
> Could it be that the color atom are not valid from ffmpeg? Can we set them
> 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
itself.
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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: convert from bt601 to bt709

Gregory Ducatel
Hi Guys,

Any update regarding this situation, I am still trying to find a proper
command line without success so far.

Thanks,

Greg


On Thu, Jun 12, 2014 at 5:46 PM, Rio Kierkels <[hidden email]> wrote:

> On 11 June 2014 19:34, Rio Kierkels <[hidden email]> 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
> to
> > > 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 <[hidden email]> wrote:
> > Could it be that the color atom are not valid from ffmpeg? Can we set
> them
> > 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
> itself.
> 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
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
12