Redcine-x Transcodes to Prores 4444 look WASHED OUT

[Johnny Friday]

I went through some renderings and I can say this.

Mac Pro 4,1 with RED ROCKET
Beta REDLINE Build
REDCINE-X 221

Rendering DPX out from REDCINE-X renders the clips with the white point being "1023" and black point is "0". I already mentioned this before, however, I found out that when you import the DPX to Apple Color, although your project was set as DPX/0-1023, it would somehow read as 64-940 to the timeline. Even the DPX header carries 0-1023 setting, it would somehow read as 64-940. So, what you can do is to override it with 0-1023 in the down right tab and set it 0-1023.

Long story short, REDCINE-X exports DPX at 0-1023, but Apple Color wrongly imports DPX at 64-940. I can pretty much say this because if you import the same clip to AfterEffects then the clip shows perfectly.

Then for ProRes4444, you don't have the same way to fix the black/white point for QT in Apple Color, so REDCINE-X has to have the black/white point control for exporting. The ProRes422 correctly exports the video range from REDCINE-X and opens up in Apple Color correctly.

I don't think it's the gamma issue. I continue to believe it is the video range issue that QT export in REDCINE-X as far as the QT4444 goes.

Kaku,
I've transcoded 422 and 4444 and they both look washed out. However, i have not yet tried a dpx and imported it into color to change settings as you've suggested......but i like the sound of that. If this is true, then this is good to know....but sure hope that the next build of RCX can tackle the issue of this problem so it will eliminate the additional steps. I know it's all new territory, so we have to wait for the beta testing and trials as we are now in order to reveal these problems. Yes....i never thought it was a gamma shift issue either after trying out build 20 vs. 221.

RED: please take another look into this so we can get some consistent transcodes.

 

[Jordan Livingston]

What I would like to know is why there is still no "official" answer we can tell our clients?! It would be fantastic if somebody said:

- this is the problem
- this is what you can / can't do about
- this is when (ballpark) we expect to have it fixed

Yes, the tools are still BETA. Yes, the tools are still free. BUT, I wouldn't be complaining at all if we just had some open and direct communication. I can't express enough how frustrating it is when a simple transcode job turns into a dead-end science experiment.

- Jordan

P.S. Also, for what it's worth, I don't notice any issues transcoding to ProResHQ or to Avid DNxHD formats. ProRes4444 success however remains illusive.

 

[Eric Haase]

What I would like to know is why there is still no "official" answer we can tell our clients?! It would be fantastic if somebody said:

- this is the problem
- this is what you can / can't do about
- this is when (ballpark) we expect to have it fixed

Yes, the tools are still BETA. Yes, the tools are still free. BUT, I wouldn't be complaining at all if we just had some open and direct communication. I can't express enough how frustrating it is when a simple transcode job turns into a dead-end science experiment.

- Jordan

P.S. Also, for what it's worth, I don't notice any issues transcoding to ProResHQ or to Avid DNxHD formats. ProRes4444 success however remains illusive.

The software is beta but the MX sensor and 30.5 are release. How are we supposed to process this footage consistently? Is there some other red software that can process mx footage with its new color science successfully?

 

[Deanan]

What I would like to know is why there is still no "official" answer we can tell our clients?! It would be fantastic if somebody said:

- this is the problem
- this is what you can / can't do about
- this is when (ballpark) we expect to have it fixed

Yes, the tools are still BETA. Yes, the tools are still free. BUT, I wouldn't be complaining at all if we just had some open and direct communication. I can't express enough how frustrating it is when a simple transcode job turns into a dead-end science experiment.

- Jordan

P.S. Also, for what it's worth, I don't notice any issues transcoding to ProResHQ or to Avid DNxHD formats. ProRes4444 success however remains illusive.

The official answer: Ask apple to fix the gamma inconsistencies in quicktime.

We can't work around something that changes depending on which program you open it in or output from or with each codec.

 

[Kaku Ito]

The official answer: Ask apple to fix the gamma inconsistencies in quicktime.

We can't work around something that changes depending on which program you open it in or output from or with each codec.

I was about to say that it is the Quick Time API issue.
Well, then I will try to see if ProRes4444 output opens up properly in AfterEffects. If it does, REDCINE-X is consistent and Apple Color has the problem opening it up.

 

[Chris Kenny]

I'm really not sure this can all be blamed on QuickTime. The problem is not just a display issue; it's visible on real external monitoring via Final Cut Pro. And it's intermittent; it seems tied to specific RedCine-X sessions and/or projects (I haven't done enough testing yet to figure out which) This is with RedCine-X 221 w/ a RedRocket.

 

[Johnny Friday]

Deanan:
Is there a workaround or white paper RED has or that you might be able to post on how BEST to get from RCX to Prores 4444 or 422 without the desaturated looks when going straight from RCX to prores? I think it was Kaku or another user that mentioned going DPX and opening in Color and changing values.....Is there a method RED can suggest for the masses that HAVE to deliver prores. I'm typically a shooter, but find i have to get my hands into color/edit when shooting my stock and I'm finding it confusing and often time consuming to continue experimenting and coming up empty handed. So hopefully we can get a bone thrown our way on HOW BEST to get to PRORES FROM R3D via RCX or other?

Thanks

 

[Gunleik Groven]

I see the same thing with RocketCine-X

Working on a workaround.
Don't really enjoy workarounds... -

 

[Johnny Friday]

STANDING BY:

....standing by for a tested or should i say safe workaround for prores transcodes from RCX....or if we need to go RCX - DPX - Prores or back to color...but would be great to know what would be recommended to get same look prores transcodes---ANYBODY? -- RED?

I'm stumped. Can not get a look in prores that resembles what i colored in RCX. My clients are buying my soft-ball answers that it is a matter of time, but don't think I'm headed down the right path. Porfavor RED....can you give up some secret info on how to get there?

Thanks

 

[Mike Gross]

STANDING BY:

....standing by for a tested or should i say safe workaround for prores transcodes from RCX....or if we need to go RCX - DPX - Prores or back to color...but would be great to know what would be recommended to get same look prores transcodes---ANYBODY? -- RED?

I'm stumped. Can not get a look in prores that resembles what i colored in RCX. My clients are buying my soft-ball answers that it is a matter of time, but don't think I'm headed down the right path. Porfavor RED....can you give up some secret info on how to get there?

Thanks

Prores 444 looks ok here. What gamma are you setup for and how are you viewing?

QT7 and QTX players will look different.

 

[Mike Gross]

I'm really not sure this can all be blamed on QuickTime. The problem is not just a display issue; it's visible on real external monitoring via Final Cut Pro. And it's intermittent; it seems tied to specific RedCine-X sessions and/or projects (I haven't done enough testing yet to figure out which) This is with RedCine-X 221 w/ a RedRocket.

FCP does it's own conversion to rgb differently just as QT7 and QTX do it differently. This is the mess that is apple and why they had to add the FCP compatibility flag to QT7 player.

 

[Gunleik Groven]

BTW

I am looking ore in the direction of setting up a separate monitor profile for the transcode to a specific codec, rather than try to make quicktime work...

Much like what we did with the DCP workflow...

 

[Chris Kenny]

I'm not sure this can all be pinned on QuickTime. We're seeing this problem on external monitoring via a Final Cut Pro with ProRes 4444 when comparing to the output of the Rocket on the same screen. So it's not just a QuickTime Player display issue or something. And it seems to be intermittent, related to specific RCX projects or sessions (I haven't done enough testing to figure out which yet). I just rendered out a long-form project that was broken up into four RCX timelines; the first rendered badly washed out, the other three were much better.

Other apps do experience strange gamma-related issues with QuickTime exports, of course, but not this kind of inconsistency; they produce predictable gamma shifts, which are a much easier problem to deal with.

I'd hazard a guess that transcoding R3D files to various sorts of ProRes is probably the single most common Red workflow, so fixing this seems like something that should be prioritized, even if it does require codec-specific hacks to work around QuickTime bugs.

 

[Mike Gross]

I'm not sure this can all be pinned on QuickTime. We're seeing this problem on external monitoring via a Final Cut Pro with ProRes 4444 when comparing to the output of the Rocket on the same screen. So it's not just a QuickTime Player display issue or something. And it seems to be intermittent, related to specific RCX projects or sessions (I haven't done enough testing to figure out which yet). I just rendered out a long-form project that was broken up into four RCX timelines; the first rendered badly washed out, the other three were much better.

Other apps do experience strange gamma-related issues with QuickTime exports, of course, but not this kind of inconsistency; they produce predictable gamma shifts, which are a much easier problem to deal with.

I'd hazard a guess that transcoding R3D files to various sorts of ProRes is probably the single most common Red workflow, so fixing this seems like something that should be prioritized, even if it does require codec-specific hacks to work around QuickTime bugs.

I spoke to an engineer in proapps about this. Final cut does it's own shift separately from quicktime so you adjust for FCP it'll look different in other apps. Then it'll look different if your expectation is to transcode back out of FCP or go to hdsdi because FCP does something different for both. On the codec side, each codec can do it's own conversion from rgb to yuv along with gamma changes.

 

[Johnny Friday]

i think this is being over-thought here. Sure FCP does something different with QT footage...not sure if it does that now. But bottom line is after doing many transcodes for a few years and using mostly old redcine, colors all looked same from R3D to transcode, but now with no color science etc....there is clearly a different look when you get to prores. As pointed out earlier in this thread i went back to redcine v20 and got my same look, but when using RCX and new color science, the prores transcodes come out desaturated and NOT what you would expect from a standard color/edit session. Now i should point out i don't do this for a living so my technical background is lacking here, but i do know what the end result looks like and i'm not getting what i expected as is the case with WYSIWYG. But i have done enough transcoding for past 15 years to clearly say that i am experiencing dramatically different results than what i expected in a color or one light session and found that using RCX for a one light is absolutely a waste of my time since now i have to go into COLOR and fix it all.

**This is not a complaint mind you. I think RED is cutting all kinds of new ground for us, but I think it needs to be pointed out and I also think that what I am seeing is not a "gamma shift" and QT problem. Otherwise it would be consistent with old Redcine v20 and earlier transcodes.

**Now, if it is really a QT problem, then we should not do ANY transcoding at all from RCX to Prores since we will not get WYSIWYG results and therefore should be transcoding to another codec.

**If that is in fact the case, what is the workflow and codec one could use with confidence to transcode to and then do any editing/coloring and then transcode over to PRORES to get consistent results? I'm sure there are a lot of folks out there that are required to send Prores deliverables as am i.

???

 

[Eric Haase]

i think this is being over-thought here. Sure FCP does something different with QT footage...not sure if it does that now. But bottom line is after doing many transcodes for a few years and using mostly old redcine, colors all looked same from R3D to transcode, but now with no color science etc....there is clearly a different look when you get to prores. As pointed out earlier in this thread i went back to redcine v20 and got my same look, but when using RCX and new color science, the prores transcodes come out desaturated and NOT what you would expect from a standard color/edit session. Now i should point out i don't do this for a living so my technical background is lacking here, but i do know what the end result looks like and i'm not getting what i expected as is the case with WYSIWYG. But i have done enough transcoding for past 15 years to clearly say that i am experiencing dramatically different results than what i expected in a color or one light session and found that using RCX for a one light is absolutely a waste of my time since now i have to go into COLOR and fix it all.

**This is not a complaint mind you. I think RED is cutting all kinds of new ground for us, but I think it needs to be pointed out and I also think that what I am seeing is not a "gamma shift" and QT problem. Otherwise it would be consistent with old Redcine v20 and earlier transcodes.

**Now, if it is really a QT problem, then we should not do ANY transcoding at all from RCX to Prores since we will not get WYSIWYG results and therefore should be transcoding to another codec.

**If that is in fact the case, what is the workflow and codec one could use with confidence to transcode to and then do any editing/coloring and then transcode over to PRORES to get consistent results? I'm sure there are a lot of folks out there that are required to send Prores deliverables as am i.

???

i agree. something is not right with RCX transcoding to ProRes. Didnt have this problem with RedAlert or RedRushes back on Build 21.

 

[David Battistella]

BTW

I am looking ore in the direction of setting up a separate monitor profile for the transcode to a specific codec, rather than try to make quicktime work...

Much like what we did with the DCP workflow...

Yes.

This is the way to go.

It seems you need to set it up to look awful in RC-X (which I know is completely assinine and ridiculous) in order for it to render and display properly in FCP.

This is pretty critical because if you are using RCX as the way to set the look of dallies and the production has asked for DVCPRO HD codec (which happens enough) if you render the look out of RCX, QT will have messed it up enough that it looks awful *(usually washed out).

There is a lot of discussion on these boards from DP's who want to onelight their dallies because it is the only chance for production to get the "look" that they intended.

That is not very easy to achieve unless you render DPX files.

I'm not sure where the problem lies with QuickTime but if you look at a KONA 3 on a Mac (as an example) it has to look at, capture and display all of the same codecs (DVCPRO, HDXDCAM, all flavours of Prores, AVID DXNXHD Uncompressed, animation, IMX, J-PEG, J-PEG 2000, on and on, etc. and it seems to handle the gamma and color spaces in some efficient way.

I'm not posting as a means of complaining, but rather, trying to find a way (workaround) to ensure that DP's are getting the dallies they intended without having to do all kinds of render tests to get acceptable looks from different codecs on any given day, which in the long run is better for RED and eliminates "hassles".

Also, personally, I can handle these issues, but you really have to have a grasp on things and be a student. A person coming to the software for the first time, sees an output codec, selects, it and expects it to work. It's really about that simple.

When it doesn't and the dallies are shipped off to some place for the edit and the editor sees washed out rushes, they do not care what the problem is, they want it fixed. The DP wants to know why the look is all fucked up.

It's problematic, there must be a way to approach it so that accurate results can be had to various codecs, maybe just limit the codecs you can output to until it is resolved because right now it is a lot of extra hassle and it's very broken.

I know this is a massive pain in the ass and must be very frustrating for the entire RED team, but it's probably more important now because "the" perception (not my perception) is that post is hard with RED.

How can we help? Can we get on Apples case or something?

David

 

[Mike Gross]

How about some screen shots of you guys are seeing because for prores I have no problems going from RCX to FCP. H.264 is where I run into look differences.

 

[Johnny Friday]

How about some screen shots of you guys are seeing because for prores I have no problems going from RCX to FCP. H.264 is where I run into look differences.

a screen shot will not reveal anything talked about. You have to look at an R3D color corrected, then look at a Prores transcoded from the R3D. You will have no reference of how the prores screenshot was colored. And posting a screen-shot here will not give you enough detail to see ANYTHING that is being discussed. You need both images side by side AND a properly calibrated monitor (to keep the playing field level) to see what the difference looks like. But yes, there is a big difference. I've noticed a few posts throughout this thread where some users say they see no difference, so I'm wondering if they are using a properly calibrated monitor first and do they have an eye to see these details. Not everyone sees it. I CLEARLY see the desaturation and I think many other color correction professionals have already verified that they see and know it exists. You can't do this on a desktop monitor and expect to see the same results.

 

[jimhare]

ProRes 4444, no gamma correction. Original RCX on top, QT result under, opened in QT7.6.6 Pro. You don't need a calibrated monitor to see these aren't even close. That's not to say the QT image isn't pleasing in its own way, it just doesn't represent my RCX image.

From day one I got in the habit of using a 3-way in FCP to bring it back to the original. Always the fastest way to finish rather than solve the problem.

I have thought about creating a monitor setting to compensate as well. Can we please keep this thread going until we figure something out? It seems to come up every few months and then fizzle out because no one has an answer.

Having said that, I don't have an answer! :mad2: