Converting Prores 444 to image Sequence without changing Gamma

achim-dietze wrote on 9/30/2016, 6:06 AM

Hi all.

I have a strange problem: I am trying to export a part of an Apple Prores Clip with an Alexa Log C Colorspace to an EXR sequence without changing gamma or colorspace. The purpose is to use it in Nuke and other tools for VFX.

Whenever I do that the Sequence never looks the same when compared to the original file neither in Vegas or Nuke. I tried project settings from 8bit, 32 bit video levels and full.

Also setting the colorspace for input and output files does not seem to have any effect at all. Somehow the colormanagement in Vegas is an enigma for me. It should be possible to convert a mov to a sequence "as is" shouldn't it? I can do it in Nuke with no problems, but I can't import an AAF or an EDL in nuke.

Any help or suggestion appreciated.

Comments

Wolfgang S. wrote on 9/30/2016, 7:32 AM

Are you doing that in VP14? Because I think there is still a bug for VP14 for ProRes 444 footage?

Desktop: PC AMD 3960X, 24x3,8 Mhz * RTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

achim-dietze wrote on 9/30/2016, 7:38 AM

I had the same problem in Vegas 13 Pro as well.

NickHope wrote on 9/30/2016, 7:51 AM

Are you doing that in VP14? Because I think there is still a bug for VP14 for ProRes 444 footage?

Not a bug. It just doesn't support it. 422 only.

Marco. wrote on 9/30/2016, 9:19 AM

Yes, though this part isn't clearly shown in the German release notes (nor on the German website) where ProRes is said to be supported but without further definition. 

achim-dietze wrote on 9/30/2016, 9:59 AM

I'm not sure if this is a prores issue though I haven't been able to test it with other formats.
At least 444 is looking completely different in Vegas than in Nuke. Have to investigate more. Still the colormanagement in Vegas is puzzling. I cannot work in 32 bit full and have my 12 or higher bit sources transformed to srgb without my 8bit sources looking completely off because Vegas assumes everthing is 12 bit or higher. But that is a different topic....

By the way the prores support is only "native without quicktime installed". With quicktime installed it was always possible to work with prores, and since you can read 444 with quicktime installed, you should be able to convert it properly. Native support or not.

NickHope wrote on 9/30/2016, 10:21 AM

By the way the prores support is only "native without quicktime installed". With quicktime installed it was always possible to work with prores, and since you can read 444 with quicktime installed, you should be able to convert it properly. Native support or not.

Unfortunately VP14 won't open ProRes 444 even if Quicktime is installed because it tries and fails to decode it with the new decoder mxhevcplug.dll, whereas VP13 just decodes it with qt7plug.dll.

MAGIX please! VP14 should check if a ProRes file is 444, and if it is, then it should leave it to Quicktime to decode if the user has that installed. Or get on and introduce native support for 444.

For now the only workaround I could image might be disabling mxhevcplug.dll

I tested with 20140117_142047_CINEC_ProRes4444.mov from http://www.cinemartin.com/cinec/samples/

 

Marco. wrote on 9/30/2016, 10:24 AM

I think there are two (or three) problems.
One – in your case – is Quicktime which will alter the gamma.
Another one is the color space. I wonder why there is no difference in your preview if you select Alexa Log C for your input color space (note, this only will work in float-point full level mode with appropiate RRT selected). If this doesn't affect your preview, something strange going on here.
And a third one – related to Quicktime again: If your source in Vegas Pro is decoded by Quicktime, it will always be handled as 8 bit. Support of color depth above 8 bit is limited in Vegas Pro. It works in certain cases, it doesn't in some others.

Wolfgang S. wrote on 10/1/2016, 1:57 AM

In other words: a solution for ProRes 444 inside Vegas would be required to overcome such an issue. Quicktime is no solution.

Desktop: PC AMD 3960X, 24x3,8 Mhz * RTX 3080 Ti (12 GB)* Blackmagic Extreme 4K 12G * QNAP Max8 10 Gb Lan * Resolve Studio 18 * Edius X* Blackmagic Pocket 6K/6K Pro, EVA1, FS7

Laptop: ProArt Studiobook 16 OLED * internal HDR preview * i9 12900H with i-GPU Iris XE * 32 GB Ram) * Geforce RTX 3070 TI 8GB * internal HDR preview on the laptop monitor * Blackmagic Ultrastudio 4K mini

HDR monitor: ProArt Monitor PA32 UCG-K 1600 nits, Atomos Sumo

Others: Edius NX (Canopus NX)-card in an old XP-System. Edius 4.6 and other systems

achim-dietze wrote on 10/1/2016, 5:30 AM

I think there are two (or three) problems.
One – in your case – is Quicktime which will alter the gamma.
Another one is the color space. I wonder why there is no difference in your preview if you select Alexa Log C for your input color space (note, this only will work in float-point full level mode with appropiate RRT selected). If this doesn't affect your preview, something strange going on here.
And a third one – related to Quicktime again: If your source in Vegas Pro is decoded by Quicktime, it will always be handled as 8 bit. Support of color depth above 8 bit is limited in Vegas Pro. It works in certain cases, it doesn't in some others.

Hi Marco thanks for the insight. That explains a lot. Also it shows that Magix has a lot of work to do before Vegas can be called fully 32bit.

I exported a 16bit exr sequence from nuke and compared it to the unaltered (prores) source in Vegas and it also looks different.

But at least switching input colorspaces has an effect. I had not turned on view transformation before. But setting view transformation to srgb also transforms my srgb sources which is nonsense because it makes it impossible to mix different sources with different bitdepth. So for me Vegas at this time is not fit as a Hub for a VFX pipeline. (Note: I have no control over what formats I get my sources in). I got an EDL mixed with prores 444 and mp4 because some producers think it is intelligent to use iphones or whatever to shoot nowadays. I have no problems handling those formats in nuke or fusion in the same comp.

Thanks all for your tips and advice.

achim-dietze wrote on 10/1/2016, 5:32 AM

By the way the prores support is only "native without quicktime installed". With quicktime installed it was always possible to work with prores, and since you can read 444 with quicktime installed, you should be able to convert it properly. Native support or not.

Unfortunately VP14 won't open ProRes 444 even if Quicktime is installed because it tries and fails to decode it with the new decoder mxhevcplug.dll, whereas VP13 just decodes it with qt7plug.dll.

MAGIX please! VP14 should check if a ProRes file is 444, and if it is, then it should leave it to Quicktime to decode if the user has that installed. Or get on and introduce native support for 444.

For now the only workaround I could image might be disabling mxhevcplug.dll

I tested with 20140117_142047_CINEC_ProRes4444.mov from http://www.cinemartin.com/cinec/samples/

 

I have no problems opening prores files in V14 with quicktime installed.

NickHope wrote on 10/1/2016, 7:45 AM

I have no problems opening prores files in V14 with quicktime installed.

444 files? Do you have an example you can share?

achim-dietze wrote on 10/1/2016, 9:47 AM

I have no problems opening prores files in V14 with quicktime installed.

444 files? Do you have an example you can share?


No, sorry. All client data. The file in the screenshot  a few posts above is a 444 file in the Vegas 14 timeline. I do not have the most recent QT version due to other problem it causes with Nuke though. My version is 7.7.5.

NickHope wrote on 10/1/2016, 11:18 AM
No, sorry. All client data. The file in the screenshot  a few posts above is a 444 file in the Vegas 14 timeline. I do not have the most recent QT version due to other problem it causes with Nuke though. My version is 7.7.5.

Mine is 7.7.6. I have just noticed that the MediaInfo report for the so-called 444 file I mentioned above actually states 422 chroma subsampling.

General
Complete name                            : E:\0-others-media\20140117_142047_CINEC_ProRes4444.mov
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   0000.02 (qt  )
File size                                : 96.8 MiB
Duration                                 : 10 s 8 ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 81.1 Mb/s
Writing application                      : Lavf55.25.100

Video
ID                                       : 1
Format                                   : ProRes
Format version                           : Version 0
Format profile                           : 422
Codec ID                                 : apcn
Duration                                 : 10 s 0 ms
Bit rate mode                            : Variable
Bit rate                                 : 81.1 Mb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 30.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 2.933
Stream size                              : 96.7 MiB (100%)
Writing library                          : fmpg
Language                                 : English
Matrix coefficients                      : BT.601

Audio
ID                                       : 2
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Mode                                     : Joint stereo
Mode extension                           : MS Stereo
Codec ID                                 : .mp3
Duration                                 : 10 s 8 ms
Bit rate mode                            : Constant
Bit rate                                 : 128 kb/s
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 kHz
Compression mode                         : Lossy
Stream size                              : 156 KiB (0%)
Writing library                          : LAME3.99.5
Language                                 : English
Default                                  : Yes
Alternate group                          : 1

If that's true then it must be failing to open in VP14 for other reasons. What does a MediaInfo report on your file show?