Vegas to mac for Prores and back issues

ddm wrote on 9/6/2014, 12:02 PM
I have been experimenting with rendering out of Vegas (to DNxHD), opening on a Mac and rendering a Prores file and then opening that back up in Vegas, hoping to achieve something constant. What I've been getting is a Prores file what has elevated levels. (the age old gamma issue?) I've tried rendering DNxHD as 709 and Computer RGB with the exact same result. Anyone have a round trip workflow that works?


videoITguy wrote on 9/6/2014, 3:08 PM
Before you start quibbling with levels change in round-trips between OS platforms, applications and codecs, you may need to compare apples to apples so to speak.

Rather than assume that levels change for one reason or another - you may have to discount how the application handles the levels.
Do this - bring your ProRes render from the Mac into a Windows OS Platform environs with Adobe Premiere as the app and NOT VegasPro.
GlennChan wrote on 9/6/2014, 3:18 PM
There are two potential issues:

1- Computer RGB versus studio RGB / levels issues.
2- The Quicktime gamma problem.

The way I used to solve #2 was... try lots of different codec combinations and see what works. I never figured out the right way to solve the problem. But try using *only* DNxHD, or only Prores, or only Quicktime Animation, or only DVCPRO50.

To solve #1:
Apply the studio RGB to computer RGB preset in the Levels FX.
Apply no Levels FX.
Apply the computer RGB to studio RGB preset in the Levels FX.

If one of these is identical, then uh... there you go. I suspect the problem is not #1.
Jedman wrote on 9/6/2014, 4:15 PM
I don't get why you would change from DnxHD to Prores when Dnx can be used on either platform?

FWIW. Years ago David Newman (Cineform) mentioned in a thread that the gamma shift issue is non existent if you use Prores 422 HQ or better.

At the time I was assembling a movie in Vegas using lots of segments edited in Final Cut X by another editor.
David was correct, as soon as I told him to render out all his clips in Prores 422HQ our gamma shifts went away.
musicvid10 wrote on 9/6/2014, 4:20 PM
Round trip should work in either Dnxhd or Cineform.
ddm wrote on 9/7/2014, 7:20 PM
Thanks for all the replies. Helpful. Here's a little more test info, haven't had a lot of time to dwell on this but...

DNxHD round trip comes back to Vegas perfectly. Prores into Premiere on the Mac and Premiere on the PC both seem fine as well. They both match the Vegas generated DNxHD. So, it seems it's a little Vegas and a little Prores. Arrrrrgh. I'm finding that almost everyone is requesting Prores and shuddering at the mention of DNxHD. Sheesh.
videoITguy wrote on 9/7/2014, 7:50 PM
Thanks, ddm for indulging in a little self-discovery and now you understand a little more about how Vegas works. And how Premiere works too!
musicvid10 wrote on 9/7/2014, 7:51 PM
So assuming your final render is ProRes, what is the point of bringing it back into Vegas?
ddm wrote on 9/7/2014, 9:37 PM
>>>So assuming your final render is ProRes, what is the point of bringing it back into Vegas?

Good question. It seemed to be a little brighter to me on my mac, although the levels on the WFM seemed very close so I brought it back into Vegas to see if seemed different and indeed it did. Now, from what I see in Premiere on both Mac and PC perhaps the Prores file will look fine on the clients system. I've been burned pretty badly years ago on a final delivery with the old Quicktime Gamma issue and I was feeling a little uneasy, although the difference is far less than the old Gamma issue I had years ago, but still... I just wish there were no surprises.
musicvid10 wrote on 9/7/2014, 10:20 PM
Examining a Prores file in Vegas is not the way to prevent surprises.
Examine it on a Mac.

[EDITED for brevity]
ddm wrote on 9/7/2014, 11:05 PM
Well, I reran my tests, making sure to name all the different renders carefully, as it was getting a little out of hand. Turns out slightly different than I first stated. A Vegas rendered DNx file brought into Mac Premiere and rendered out as Prores, and then brought back into Premiere on Mac has different level than the Vegas original. So not just Vegas, but Premiere Mac (and Premiere PC) show the Prores render levels as different from the original. The same Vegas Dnx render, rerendered on Mac in both Apple's Compressor and in Premiere render a DNx file that is identical to the Vegas original. If I load the Vegas rendered DNX and the Prores rendered file and the Mac re-rendered DNx file into FCPX, the DNx files are the same and the Prores is different, visually and by the WFM. Which, btw, is exactly how they all appear in the Vegas timeline as well. So clearly, something is happening to the Prores file.
wandering journalist wrote on 9/8/2014, 10:17 AM
Interesting thread - In July I just spent about two weeks pulling my hair out trying to get a 90 minute documentary edited in Vegas Pro rendered into Prores 422 HQ for delivery. After reading about all the gamma issues with Prores, I was pleasantly surprised that the Prores 422 HQ passed QC at the lab. I wish I had known about the file format mentioned here for rendering out of Vegas though... hadn't thought of DnxHD... things you learn ;)

musicvid10 wrote on 9/8/2014, 10:51 AM
The open source ffmpeg library for Windows does have a Prores422HQ encoder, but I don't know if it will pass muster with the Apple-compulsive editors and broacasters.

Many contributers at videohelp and elsewhere echo the notion that DNxHD is the way to go.

videoITguy wrote on 9/8/2014, 11:18 AM
The last few posts in this thread continue to throw confusion at the process. In particular ddm says that test ran fine encoding on a Mac and then played back in Premiere on a PC - then restates a different test parameter and implies that it doesn't.
This brings up real concern about what ddm considers to be the test criteria and how to measure it.
Further post by wanderingjournalist states that a ProRes Encode on a PC (ask what software using ProRes?) passed a delivery test to a client - what was the criteria to pass such a test.
The latest iterations of ProRes encode on a PC with non-Adobe software have proven viable in third world countries. What does USA market bring to the test that third-world countries forgive.
musicvid10 wrote on 9/8/2014, 12:01 PM
"The latest iterations of ProRes encode on a PC with non-Adobe software have proven viable in third world countries. What does USA market bring to the test that third-world countries forgive."

Likewise, it would be nice to know where that generalization came from. But assuming it's partially true, it's a safe bet that commercial licensing scrutiny is at a higher level in the US.
videoITguy wrote on 9/8/2014, 12:05 PM
Encoding on a PC with the right Pro-Res encoder does what ? to the license of a distributed file that is sent to another platform. Can you tell the difference?
musicvid10 wrote on 9/8/2014, 3:19 PM
Sets the codec ID flag, maybe some optional information.
videoITguy wrote on 9/8/2014, 3:35 PM
If its metadata in the header - it is easy to edit. In fact metadata can be force fed by a utility so it's hardly a lockout.
musicvid10 wrote on 9/8/2014, 7:58 PM
I presume it's in the atom, not the user metadata, which is text.
Read 'flag', not 'tag.'

How handy are you with a hex editor?

musicvid10 wrote on 9/8/2014, 10:21 PM
Waiting for your source for the 'third-world countries' statement.
videoITguy wrote on 9/8/2014, 11:23 PM
Many of the sources for code to write Pro-Res on the PC are based in countries such as Brazil and Russia. In fact Russian code writers have developed comprehensive media managers like the kind we used to have and wish for in VegasPro of some years ago - these comprehensive tools are built to index Pro-res writtten on the PC.

As for broadcaster using unofficial ProRes license - it is easy in the Brazil and Mexico markets.
musicvid10 wrote on 9/9/2014, 7:18 AM
I could swear I asked for the source of your information.
I don't doubt there are pirated encoders, but you seem to be advocating chicanery, something like sewing a Gucci label on a cheap handbag?

For the record, ffmpeg/ffmbc is legal, open-source software under public license. But they don't attempt to impersonate the commercially licensed product, nor are they supported in any way by Apple, that I am able to determine. If some commercial broadcasters choose to accept ffmbc, it is an informed decision, possibly to the detriment of existing agreements. But there is nothing that says they have to accept any flavor of Prores someone throws their way.