Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

RocketCine-X MXF non-709-compliant

J

Job ter Burg

Well-known member
Joined
Nov 23, 2007
Messages
203
Reaction score
0
Points
0
Age
54
Website
www.terburg.com
Today, three other editors and me installed my Rocket card in one of our Mac Pros, and wanted to test the RocketCine-X workflow as described in the guide @avid.com.

It's simple and fast BUT it results in Avid media with non-709-compliant video levels (blacks are at 0 rather than 16, top whites are way into 255). We see no way to adjust any setting for that.

We tried to do DNxHD36 Quicktime exports, fast imported those into Avid, and those imports DO have legal 709 colors.



We're now downloading RedCine-X to see if that may help in any way, but at this point in time, it does not appear possible to make 709 compliant Avid MXF mediafiles with RocketCine-X.

I would love to stand corrected, if there's any setting we might have been missing.


P.S.: In RedCine-X, we get the same color levels results.
 
Job ter Burg

You responded to a thread I posted in November, about this exact problem and helped me with my understanding of Avid settings for Color Levels on import.

Micheal from Avid said he would try a test but the only response was for a test he did with TIFF files.

I have seen this problem since November and would love to know how if I am missing a setting that creates the correct color levels for the MXF files. Until then I'll continue to make Quicktimes and import (even with fast import much slower process if you have a lot of material).

I'm been surprised not to see more in the forums about this, either not many people are using this workflow or I'm doing something wrong.


As an aside new 64 bit drivers for the Rocket Card on Mac would be nice hate to reboot everytime I want to use the card.

AY
 
Deanan and I have been working this issue and it is an issue of working "full range" 709 (0-255 for 8 bit) or constrained (16-235 for 8 bit) when creating MXF/wrapped DNxHD files. My assumption up until not too long ago, and wrong at that was selecting REC709 as an output gamma did the constrain. Deanan can be more explicit about exact plans, but I believe there will be an option to choose full range or constrained when creating MXF/DNxHD files in a future release.

Michael
 
Hopefully this happens soon.

The ability to use the Rocket Card to create MXFs with ALE is a great workflow for Avid based production.
 
MichaelP said:
…I believe there will be an option to choose full range or constrained when creating MXF/DNxHD files in a future release.
Click to expand...

I thought that DNxHD files were always 'legal' levels internally. So why would one want the option not to make the appropriate levels adjustment when writing MXF files? Would this not be giving users the option to create the files incorrectly, which is not a very useful option!?
 
Depends on workflow... the last film I did I did a full range 709 workflow so I could have full untouched range for the file export to the DI system I used. This was not shot on RED, so it worked for that production. For this scenario it is nice to have the option, but default to contrained.

Michael
 
MichaelP said:
Depends on workflow... the last film I did I did a full range 709 workflow so I could have full untouched range for the file export to the DI system I used. This was not shot on RED, so it worked for that production. For this scenario it is nice to have the option, but default to contrained.

Michael
Click to expand...

Interesting idea.

So you send technically 'illegal' data to the DNxHD encoder, presumably either accepting its incorrect levels during editorial, or possibly using a LUT in the monitoring path to correct for it. Then the DI system reads the DNxHD files and interprets the data as full range.

Is DNxHD absolutely transparent to this process? I cannot immediately work out in my head the gamut implications of the RGB>YCbCr>RGB conversions (with 'illegal' levels) involved, if that is what is happening.
 
Michael Lindsay said:
I've used super-white and black values in my post path many times.. Even when shooting tape I would often turn of 100% clipping to allow a little more headroom through.
Click to expand...

I absolutely understand the necessity of preserving super-white and sub-black, when that's what they are. Most video cameras produce super-whites, and workflows which clip those should be avoided. Clipping happens all to easily for example when rendering through After Effects using QuickTime.

I'm just trying to wrap my head around the idea of mapping RGB peak white to YCbCr super-white, then passing that through a pipe which treats it only as YCbCr, then converting back to RGB. May well be fine, but I would certainly test for transparency before implementing such a workflow.
 
Hi Nick

Your 100% correct...

However I am happy to assume (with the little testing we did) DNxHD is as transparent in mapping in 444 0-255 to 422 0-255 as it is in mapping to to 422 16-235. There are problems with a post path that involves finishing with DNxHD but this isn't one of them (for me).

A option for both would be good..

regards

Michael L
 
You must log in or register to reply here.
Back
Top