Redcine-x Transcodes to Prores 4444 look WASHED OUT

[Johnny Friday]

So having difficulty with redcin-x build 221 and trascoding to prores 4444.

I'm using MacPro, redcine-x build 221, redrocket card that is running from HD-SDI dual link out into an AJA Hi5-3G that converts HD-SDI to HDMi and that is connected to my HP Dreamcolor monitor.

The monitor is set to REC 709 that has a gamma of 2.4 (not 2.2)--I suppose this is normal for REC 709 ? I have many options with the HP Dreamcolor for colorspace settings such as:
*Full; AdobeRGB, Rec.601, and a few others, but REC.709 seems appropriate.

PROBLEM:
everything goes nice while using redcine-x v221 and image looks great on my HP dreamcolor. My other monitor is a Dell u2410 that has the viewer and other workspace on it. It does not match perfect the dreamcolor, but it's not terrible. So, when making color corrections everything is good, then i go to transcode to Prores 4444 and my settings are:
Motion:
frame per second: 29.97 (it was shot at that speed)
Gamma Correction: None
Depth: millions of collors +

**When i finally get the file baked as a .mov and play it, the image/movie is very unsaturated and has a WASHED OUT look to it. It's as if all the color I put into it with the first pass of color correction was for nothing. It is quite frankly not even a close representation of the image i created.

*I also had downloaded the latest quicktime component and installed it in the redcine library. So that was done.

Anyone have an explanation or fix?

[David Battistella]

It sounds like the grade is not applying to the clip you are wanting to render.

To test this I set up several output settings.

One of each for prores 4444, uncompressed hd, DVCPROHD, AVID DNXHD, etc. to see how all the different codecs would render.

Create a 5 frame clip in the timeline and then render out each output setting and compare the QT files. You will see that QT handles the gamma for each differently.

As a workaround to get the gamma to match you might have to create presets for each codec that will yield a correct gamma in the rendered file.

This is a problem in quicktime in that it will randomly assign GAMMA to a specific codec even if RCX is asking it to render a specific gamma, QT will choose it's own.

I have found that PRORES is the most accurate compared to the INternal monitoring in RC-X.

It's pretty hard to get all the GAMMA settings right when there are so many output variables. You really have to test each one and figure out the "gamma offset". Plus there are many values being plugged into the render data including curves, shadow, exposure and FLUT that will have an impact on what the blacks look like, so it can be tricky to get it right, but you have to test.

David

[Deanan]

What application are you playing it back on?

[Johnny Friday]

Deanan,
I'm just playing back the Quicktime files on both Quicktime x and Quicktime pro v.7 And the look is the same on each of those....I've transcoded in the past on older versions of redcine-x and cannot recall images such as these. Just look too bright/overexposed and washed out of color.

David: I'm trying a variety of outputs now.

[Jordan Livingston]

Dear John,

Do you have the "Use restricted SMPTE range" check box checked in your RC-X Export Preset? If so, try un-checking it. I have found this to produce flatter results in the ProRes files than how the grade appears in RC-X.

ALSO, when you view your ProRes files, are you viewing them in the QuickTime player or in Final Cut Pro? Try viewing them in Final Cut Pro - sometimes the QuickTime player doesn't look accurate even though the files themselves look great in FCP, Color, etc.

Best,

- Jordan

[Johnny Friday]

It sounds like the grade is not applying to the clip you are wanting to render.

To test this I set up several output settings.

One of each for prores 4444, uncompressed hd, DVCPROHD, AVID DNXHD, etc. to see how all the different codecs would render.

Create a 5 frame clip in the timeline and then render out each output setting and compare the QT files. You will see that QT handles the gamma for each differently.

As a workaround to get the gamma to match you might have to create presets for each codec that will yield a correct gamma in the rendered file.

This is a problem in quicktime in that it will randomly assign GAMMA to a specific codec even if RCX is asking it to render a specific gamma, QT will choose it's own.

I have found that PRORES is the most accurate compared to the INternal monitoring in RC-X.

It's pretty hard to get all the GAMMA settings right when there are so many output variables. You really have to test each one and figure out the "gamma offset". Plus there are many values being plugged into the render data including curves, shadow, exposure and FLUT™™ that will have an impact on what the blacks look like, so it can be tricky to get it right, but you have to test.

David

David, first off thanks for the assistance. I tried a variety of presets and found that my best results to get the richest colors back out of QT compared to what i was grading in RCX was to choose prores 444 or 422HQ and select Gamma as "NONE" instead of Automatic. That was about my only choice in the presets other than checking "restrict SMPTE" i tried with it checked and unchecked and did not find much difference in the QT prores file that was ouput---or i might say a very slight difference....which lead me to keep it unchecked.


Dear John,

Do you have the "Use restricted SMPTE range" check box checked in your RC-X Export Preset? If so, try un-checking it. I have found this to produce flatter results in the ProRes files than how the grade appears in RC-X.

ALSO, when you view your ProRes files, are you viewing them in the QuickTime player or in Final Cut Pro? Try viewing them in Final Cut Pro - sometimes the QuickTime player doesn't look accurate even though the files themselves look great in FCP, Color, etc.

Best,

- Jordan

Jordan, I have only been viewing in the QT file and have not yet checked in FCP. And as you see in my post above, i did uncheck "restrict SMPTE" and results were slightly better.


RESULTS THUS FAR:
to re-hash, it seems in my case presetting prores4444 and selecting Gamma as "NONE" gives me a better look. HOWEVER, the QT movie is still not as nice as the RCX image i graded.

Hardware: Keep in mind, i am viewing RCX image via REDROCKET card output via HD-SDI into AJA Hi5-3G that basically converts 12bit HD-SDI to 10bit HDMI into my HP dreamcolor that is setup with the REC.709 color space. So, in essence i'm viewing the RCX images at 10bit and then when i go to view the QT movie file i created, i then switch my HP monitor to DVI input from my mac tower that is of course only 8bit --AND i am running two monitors at once off the graphics card--NOT SURE IF RUNNING TWO MONITORS MAY ALSO BE A PROBLEM....but result is that the QT images viewed on my same monitor, but at 8bit are less rich than they are viewing on RCX at 10bit. But the difference is not slight....it's quite noticeable. They are less saturated and slightly washed out...not nearly as bad as before when i had Gamma set to "Automatic".

Could there be another issue in order to get them to match completely? I don't recall having these issues in the past on Redcine v. 20.

Thanks to all for the assistance.

Jordan, I'll have a look in FCP within the viewer at the QT movie and add feedback on that as well.....and then again in color.

[David Battistella]

Yes,

I found that switching off automatic was an improvment. It would be good if you could look at the files from FCP in 10-bit via a KON card and you might be pleasantly surprised at the results.

David

[Johnny Friday]

Yes,

I found that switching off automatic was an improvment. It would be good if you could look at the files from FCP in 10-bit via a KON card and you might be pleasantly surprised at the results.

David

I wish....i know. AH---just thought of what i can do...I dont' have a Kona Card, BUT i do have MXO2 and that connects via HDMI---should work into my Dreamcolor. I'll have to check that as well. I may not get to all of this tonight....I expect tomorrow or a day later, but i think that would get things closer to a firm result one way or the other. But i must say that 8bit vs 10bit kind of sounds out there to see a big difference. You may in fact be right, but I've done quite a bit of color work via 8bit and just don't recall seeing a difference like this when viewing 10 or 12 bit. But now my eye is much more keen on CC work since i am doing it almost every day now.

[Johnny Friday]

Viewed QT reders in Color as well as Final Cut Pro with output to my HP Dreamcolor @ 8bit color (not 10bit like my Rocket Card ouputs).

Looks better, but still slightly less saturated than the RCX look out to 10bit monitoring.

I'm beginning to think that it really is a question of 8bit monitoring vs 10 bit monitoring. ???

Next is to try viewing via my matrox MXO2 LE out via hdmi (10bit) to see if image will look as i graded it in RCX and viewing at 10bit on my Dreamcolor.

[Kaku Ito]

John,

In REC709, gamma level is not specified. People choose it according to the ambient light surrounding of the room. Safe bet is 2.2 in normally lighted situation, but if you darken the room then higher number like 2.3 or 2.4 is used. For example, for DCI, the gamma level is 2.6.

In my opinion, Dream Color is over saturated when you use it with Mac.

[Johnny Friday]

John,

In REC709, gamma level is not specified. People choose it according to the ambient light surrounding of the room. Safe bet is 2.2 in normally lighted situation, but if you darken the room then higher number like 2.3 or 2.4 is used. For example, for DCI, the gamma level is 2.6.

In my opinion, Dream Color is over saturated when you use it with Mac.

Kaku,
I believe it is set to 2.4 last time i checked. I can lower it to 2.2 easy enough and should try that tomorrow. You may be right that it is a bit oversaturated. It was also noted as too bright, but i lowered the luminence level from 250 to 130 to match better a plasma tv---that helped a lot already. Not sure if i can do anything about saturation, but I would also need to compare it to another cc monitor.

[Johnny Friday]

Ok, after further review i can only say that the QT movies are completely washed out using the new redcine-x, with the QT 4.1 plugin --- in my case.

They seem to look fine on my dreamcolor (slightly less saturated than original looks in RCX); but when i email them to anyone and they view on their macs with non dreamcolor or non cc monitor they look terrible. Really unsaturated. I can make a far superior looking QT file by taking them into FCP natively and outputting them. But i loose the Rocketcard and speed.

I also tested different ouputs and different monitor settings on my Dreamcolor:
*best results are: monitor "Full"(dreamcolor setting--choices are full; rec709) using Redcolor/Redgamma(in RCX)

**When i take the files into FCP they look a bit better, in fact really a lot better than if viewing directly from QT. But this is strange as I've never seen this before when making QT movies. Now that I am using much better monitoring and control using Tangent wave, the results seem to be disasterous.

Frustrating! Any chance this can be due to the QT plugin components just not working at their best ?

[Kaku Ito]

You have to sort out your system. Can you list up what you have?

If you monitor over saturated display to work on grading, then the result looks under saturated in other environment then simply you tend to lessen the saturation by looking at over saturated monitor, so the render becomes undersaturated.

Any of the presets of Dream Color with Mac Pro's ATI GPU did not satisfy me even with Eyeone Display 2 calibration applied (not saying it's impossible but didn't come automatic). I ended up adjusting the saturation and color balance using Matrox MXO"s DVI calibration but that is because I had it and I'm not saying you need one.

If you have the gamma setting to 2.4 then adjust the picture according to that, in normal situation, the output will become washed out if you monitor the results in 2.2 (Snow Leopard's default) or 1.8 (Leopard's default).

[David Battistella]

John

I ran some tests lady night and Mae presets for all the qt codecs.

My results:
these codecs were washed out:
dvcprohd 720 and 1080
apple uncompressed 10-bit
apple prores 4444

these looked good:
prores 422 hq
prores 422 lt
prores 422 proxy

I looked at all of the files in OsX Qt player. I'll look at them today in fcp.

David

[Johnny Friday]

You have to sort out your system. Can you list up what you have?

If you monitor over saturated display to work on grading, then the result looks under saturated in other environment then simply you tend to lessen the saturation by looking at over saturated monitor, so the render becomes undersaturated.

Any of the presets of Dream Color with Mac Pro's ATI GPU did not satisfy me even with Eyeone Display 2 calibration applied (not saying it's impossible but didn't come automatic). I ended up adjusting the saturation and color balance using Matrox MXO"s DVI calibration but that is because I had it and I'm not saying you need one.

If you have the gamma setting to 2.4 then adjust the picture according to that, in normal situation, the output will become washed out if you monitor the results in 2.2 (Snow Leopard's default) or 1.8 (Leopard's default).

Kaku, thanks for input:
I'm running as follows:
*Mac 2.26 dual (8core)
*OS-Snowleopard 10.6.3
*Quicktime Pro v7 (I canned Quicktime X) (monitoring setup for FCP)
*32gigs ram
*ATI 4870 Graphics card to Dell U2410 monitor
*Redrocket card running out of HD-SDI into AJA Hi5-3G converting to HDMI into HP Dreamcolor
*running RCX build 221
*QT Redcode component 4.1 installed
*coloring from Tangent wave

What you say makes perfect sense if i am grading on my Dreacolor in its emulation of REC709 that has colorspace setup as 2.4---the transcodes look seriously flawed (washed out) when viewing them on my Dell that is setup monitoring over DVI at Macs Gamma of 2.2 When i switch my Dreamcolor over to DVI monitoring (still emulating REC.709) and view that same QT clip, it does look more saturated and quality IS better, but still not what I was viewing when coloring from RCX---but i am now only in 8bit with DVI not 10bit when i'm viewing from HDMI on RCX. Can 8bit to 10bit REALLY make that much difference to see by eye?

I had tried a variety of monitor emulation modes as well as transcode outputs as recomended by David and found i get slightly better looks if the Dreamcolor is setup in its colorspace "FULL" and luminence is turned down from 250 to 130-150 range. But i still have same washed out looks in the QT transcodes. I'm presuming that this SHOULD NOT be the case or would this be correct? My Dell's are not color correction monitors and nor are the Cinema display, but never have i seen such a washed out look while viewing a QT transcode on other folks systems. I was thinking that maybe since I am working on a color correct monitor for the first time then this could be the case, but I have my doubts.

[Johnny Friday]

John

I ran some tests lady night and Mae presets for all the qt codecs.

My results:
these codecs were washed out:
dvcprohd 720 and 1080
apple uncompressed 10-bit
apple prores 4444

these looked good:
prores 422 hq
prores 422 lt
prores 422 proxy

I looked at all of the files in OsX Qt player. I'll look at them today in fcp.

David

Thanks David,
I also tried Prores 4444; uncompressed 10bit and 422HQ: they all yielded a similar washed out look for me. What i have not yet tried is to go back to build 104 RCX to see if i get a different result. BUt i think i also need to change the QT component if i do that in order to take that out of the equation because my suspicion is that the beta QT component might be the culprit (i'm hoping). Also, i'm looking at all underwater shots with a blue background and dark subjects....So the washed out look is even more exagerated under those circumstances. ---I'd be glad to email you either a tiff from RCX or even a QTprores clip for review so you can see just how exagerated the washed out look is. I think posting here will not show the full resolution of the Tiff and how washed out it is. I'm anxiously awaiting the next build since i believe that red seems to be aware (prior posts from others) that there is some difference in saturation on transcoded clips, but some of the clips i saw posted were minor, but they also were not in the environment i work under where background of blue can seriously highlight the washed out effect.

I'll try some land shots today since all i had been working on for past few days were underwater.
Thanks David

[Kaku Ito]

Make sure the export gamma choice not to be "auto". I think Apple still is kinda messing with what they think it is proper to process gamma shifting.

Also, some cases REDCINE-X ouputs 0 to 1023 video range file with the picture mapped to 64 to 940 range, then when such clips is imported to FCP, FCP automatically adjusts and display correctly, but when you send the timeline to Apple Color, it opens as 0 to 1023 video range then the black area gets lifted up (this might be you are calling washed out?).

[Johnny Friday]

Make sure the export gamma choice not to be "auto". I think Apple still is kinda messing with what they think it is proper to process gamma shifting.

Also, some cases REDCINE-X ouputs 0 to 1023 video range file with the picture mapped to 64 to 940 range, then when such clips is imported to FCP, FCP automatically adjusts and display correctly, but when you send the timeline to Apple Color, it opens as 0 to 1023 video range then the black area gets lifted up (this might be you are calling washed out?).

Kaku,
have my export settings within RC-X set to Gamma "NONE" and that does show a marketed difference. As for the remainder of your post, that's a bit beyond my simple abilities....but i get it conceptually, however not sure how to make adjustments for this. Basically the QT should look fairly close to the color corrected image no? This should just be basic yes? As long as i have all the settings correct in RC-X and new QT component to read new color science and flut.

I'll post a tiff next so you can see how washed out...

[David Battistella]

Looked at all the files in FCP and here are the results.

Correct gamma compared to RC-X

PR4444
PR422 HQ
PR LT
DPX


Raised GAMMA (blacks) compared to RC-X

DVPROHD
UNCOMPRESSED 10 bit
SHEER
PR Proxy
PR 422


What a Charlie Foxtrot this is.

If I open all of these files in QT the reverse happens with ProRes.

Advice.
Before creating a deliverable. Know what software the files will be edited in. Test. test . test.

David

[Johnny Friday]

i thought i would test a tiff output vs a qt output to see if there was any difference. BUT, the TIFF matched the QT. So guess that at least there is conformity in that respect. I'm going to continue on with testing here.

[Johnny Friday]

Looked at all the files in FCP and here are the results.

Correct gamma compared to RC-X

PR4444
PR422 HQ
PR LT
DPX


Raised GAMMA (blacks) compared to RC-X

DVPROHD
UNCOMPRESSED 10 bit
SHEER
PR Proxy
PR 422


What a Charlie Foxtrot this is.

If I open all of these files in QT the reverse happens with ProRes.

Advice.
Before creating a deliverable. Know what software the files will be edited in. Test. test . test.

David

Yes, that is about what i experienced. ALTHOUGH for my looking at underwater footage with big blue background with raised whites....I can see in MUCH greater detail the washout effect. If i import that pr4444 into FCP it does look better, but still not nearly as good as in RC-X--i would not say that it matches the look, but just has 50% better saturation as compared to viewing it in QT

[Johnny Friday]

Here is a TIFF file that I had worked from Rocketcine-X using dreamcolor monitored from HD-SDI thru AJA to HDMI so viewing and correcting at 10bit with dreamcolor monitor set to "FULL" as colorspace with the Gamma in FULL mode set to 2.2

Looked great on the Dreamcolor monitor, but on my Mac via DVI and ATI 4870HD graphics card at 8bit using Mac's gamma of 2.2 it looks washed out and de-saturated. Not sure if this screenshot will do this rant justice.

Comments?

EDIT: the screenshot does not show anything....since i have no reference.

[Johnny Friday]

Ok....I think I've run out of ideas and tests. I would be perfectly willing to send you guys a clip to see for yourselves what i have tested. Say (as David suggested) a small 2-3 second clip to see for yourselves. It would be however nice if one of you had a dreamcolor to monitor extactly what i see, but at the least a QT prores 4444 clip transcoded may tell???

[Simon Blackledge]

Is this not because the dreamcolour is a wide gamut display ?

going to 8 will clips/distort your chroma in an image no ?

s

[Johnny Friday]

Is this not because the dreamcolour is a wide gamut display ?

going to 8 will clips/distort your chroma in an image no ?

s

I don't think so...In fact have some new examples to show the HUGE change in flavours.

[Johnny Friday]

Here are two screenshots of the EXACT same image BUT one was corrected in Redcine v 20 and the other in Redcine build 221 with redcode QT component 4.1 added.

You'll notice a big difference in the saturation in the two shots. I had originally corrected the RCv20 image using my Dell U2410 and the image showed on my non-calibrated screen nicely, but on a REC.709 it is darker and more saturated--but the difference is not ovewhelming.

The image RC-X-build221 was corrected using RC-X and corrected on my Dreamcolor emulating REC709. Looked great while correcting on the monitor, but when I output a QT it looked terrible and washed out.

CONCLUSION: i can only come to the conclusion (no science--only my eyes and two days of testing) that RC-X build 221 and the new QT component are not outputting the new color-science correctly. It is clear that with Redcine V20 i could get images to look fairly close to what i saw them looking like in Redcine and the prores transcodes, but that is NOT the case in my recent transcodes using build 221.

Comments?? other ideas?

[Johnny Friday]

I can't be the only one experiencing this problem??
This a huge difference.....

[Kaku Ito]

i thought i would test a tiff output vs a qt output to see if there was any difference. BUT, the TIFF matched the QT. So guess that at least there is conformity in that respect. I'm going to continue on with testing here.

TIFF output becomes gamma 1.8 at default even in Snow Leopard, so be careful.

[Kaku Ito]

please post the short r3d.

[Johnny Friday]

TIFF output becomes gamma 1.8 at default even in Snow Leopard, so be careful.

The two images i posted were only screen grabs off of my mac from the original QT files beginning at frame one. So all they are is representative of the color de-saturation effect that i am seeing and represent the problem i see when outputting the prores transcodes. It's quite easy to notice that the old RC held saturation and the new RC-X looses saturation after transcoding to prores.

I'll see about posting two clips tomorrow.

[Antoine Fabi]

Hi Kaku and John,

Yep...QT gamma is still all over the place. It's not serious.
Snow Leopard was supposed to solve the gamma problem... :)

Just for fun, try to calibrate your monitor on a Mac using their calibration tool and then set it to gamma 2.2 as recommended.

Then, compare the QT look on your computer monitor (now calibrated) to a calibrated NTSC or HD monitor...NOT THE SAME...!!!!

And now, compare the QT X output to QT 7 output...NOT NECESSARILY THE SAME...!!!!

Oh...because it's not finished, do we check the "match FCP" in QT 7 Pro prefs ?

A real joke...

Cheers!

Antoine

[Kaku Ito]

match FCP (which means gamma 1.8 monitoring but to make it 2.2) is really bad and unspecific name. People who started using from Snow Leopard and FCS3 would get really confused.

[Johnny Friday]

Hi Kaku and John,

Yep...QT gamma is still all over the place. It's not serious.
Snow Leopard was supposed to solve the gamma problem... :)

Just for fun, try to calibrate your monitor on a Mac using their calibration tool and then set it to gamma 2.2 as recommended.

Then, compare the QT look on your computer monitor (now calibrated) to a calibrated NTSC or HD monitor...NOT THE SAME...!!!!

And now, compare the QT X output to QT 7 output...NOT NECESSARILY THE SAME...!!!!

Oh...because it's not finished, do we check the "match FCP" in QT 7 Pro prefs ?

A real joke...

Cheers!

Antoine

Yes, the monitoring is a bit all over. I have noticed that. However the looks seem to be slight IMO--but you can see them. The real culprit where I see a HUGE difference is when monitoring them after transcode and just looking at the basic image--it's WAY off. If i take that transcode into FCP or to my Dell Monitor from Mac (gamma set 2.2 with FCP monitoring on) you see a small gamma shift and same (and expected) when i take it to my calibrated Dreamcolor monitor plugged into the DVI port on my mac---but that is really expected since my DC is emulating a REC709 monitor with gamma of 2.4

I also (last night) checked and monitored off of my MXO2 and looks EVEN different--funny, but the transcodes look better when monitoring off of MXO2 via HDMI out to my LCD TV---when running them through FCP.

However, still takes this main discussion far from the point which is that the QT files look like hell when played directly within QT. There are FAR from representative of what one color corrected in RC-X.

I'll try to post a few clips later today and pop back and give a link.

[Eric Haase]

Having the same issues playing around with some footage I shot. Just testing on my imac for fun and noticing that what i see in redcine x (latest version) is nowhere close to what i get after rendering a prores or avid dnxhd QuickTime. The quick times are more washed out and destaurated when viewed in QuickTime x, QuickTime 7, or FCP.

This is terribly disconcerting. As a DP if i grade dailies on set but the delivered transcode does not match, my job is on the line. Color consistency should be on the top of reds priority list for redcine x.

[Jordan Livingston]

Have you tried setting gamma correction to "Automatic" in your video export settings? I have found that this tends to produce more accurate results on my system than when the gamma gamma correction option is "off," and I've been told by another DIT that this is the root of the "washed out" problem.

Hope this helps...

- Jordan

[Johnny Friday]

Have you tried setting gamma correction to "Automatic" in your video export settings? I have found that this tends to produce more accurate results on my system than when the gamma gamma correction option is "off," and I've been told by another DIT that this is the root of the "washed out" problem.

Hope this helps...

- Jordan

I believe you mean set it to "NONE" yes? When you set to none then QT will play it at the gamma you set it at. If you choose Automatic, then there is a chance that it may play at 1.8 instead of 2.2.....this is how I understand the transcode option of checking none vs. automatic.

[Johnny Friday]

Having the same issues playing around with some footage I shot. Just testing on my imac for fun and noticing that what i see in redcine x (latest version) is nowhere close to what i get after rendering a prores or avid dnxhd QuickTime. The quick times are more washed out and destaurated when viewed in QuickTime x, QuickTime 7, or FCP.

This is terribly disconcerting. As a DP if i grade dailies on set but the delivered transcode does not match, my job is on the line. Color consistency should be on the top of reds priority list for redcine x.

Ok...now i know i am not alone in seeing this and it's not my system setup. In fact if you look back in my posts i showed where redcine v20 was producing consistent and very good results when transcoding to prores. Then in the newer redcine-x builds and the new QT codec i seem to get nothing but washed out and desaturated transcodes out of redcine-x. I'm confident of my results since i loaded the redcine v20 again yesterday, then redcine-x build 104 and redcine-x build 221 and my tests yielded same results. So as you say....job is on the line. There is NO WAY IN HELL i can send out these transcodes to my clients or to my stock house to put on the web and for sale since they look horrible. I'm better to go back to build 20 with the old color science and no flut control and do my transcodes from there until we get a build that will yield WYSIWYG---or at least 90% close to that.

[jimhare]

Even with NONE selected it still comes out with less contrast and saturation. Not severe but DEFINITELY noticeable. Creates a bit of guesswork and compensating during edit/grade. Not a great situation and would love for it to be addressed.


Have you tried setting gamma correction to "Automatic" in your video export settings? I have found that this tends to produce more accurate results on my system than when the gamma gamma correction option is "off," and I've been told by another DIT that this is the root of the "washed out" problem.

Hope this helps...

- Jordan

[Johnny Friday]

Even with NONE selected it still comes out with less contrast and saturation. Not severe but DEFINITELY noticeable. Creates a bit of guesswork and compensating during edit/grade. Not a great situation and would love for it to be addressed.

Yes, definately, and choosing none as i understand allows FCP & QT to use the gamma it was transcoded to. There is a slight difference in saturation, BUT in cases i am seeing the problem---underwater and big blue background---the gamma shift is HUGE. Topside footage I've shot does not show as much washout since not those big blue underwater backgrounds with lots of light.

So for me the washout/desaturation is HUGE

[Jordan Livingston]

I believe you mean set it to "NONE" yes? When you set to none then QT will play it at the gamma you set it at. If you choose Automatic, then there is a chance that it may play at 1.8 instead of 2.2.....this is how I understand the transcode option of checking none vs. automatic.

I would try it both ways... If "none" isn't looking proper, try "automatic." I've had successful results both ways, but if you're transcoding to ProRes HQ, 4444, or Avid DNxHD, automatic should select 2.2 gamma.

- Jordan

[Johnny Friday]

I would try it both ways... If "none" isn't looking proper, try "automatic." I've had successful results both ways, but if you're transcoding to ProRes HQ, 4444, or Avid DNxHD, automatic should select 2.2 gamma.

- Jordan

Best results in my case seem to be set to NONE.

[David Battistella]

can you use 422 HQ in the meantime?

why is 4444 so important to you? when it's fixxed/solved you can re-render all of the material.


David

[Johnny Friday]

can you use 422 HQ in the meantime?

why is 4444 so important to you? when it's fixxed/solved you can re-render all of the material.


David

I get the same results David. In fact for 422; 422hq and 4444. Prores is my usual deliverable and in fact what i'm asked to supply so i'd be pleased to output another way, but from another users input it sounds like ALL transcodes from redcine-x build 221 and using beta QT are washed out and of no use as a finished deliverable as they were in the past for me using redince v20

[Eric Haase]

I get the same results David. In fact for 422; 422hq and 4444. Prores is my usual deliverable and in fact what i'm asked to supply so i'd be pleased to output another way, but from another users input it sounds like ALL transcodes from redcine-x build 221 and using beta QT are washed out and of no use as a finished deliverable as they were in the past for me using redince v20

Yes they are all washed out. SO frustrating.

[David Battistella]

I'm not getting that with the 422 HQ, just the 4444

David

[Johnny Friday]

I'm not getting that with the 422 HQ, just the 4444

David

Very interesting David. I get washed out look with every transcode i have done now with the new b.221 and beta quicktime.

[Johnny Friday]

David, you enabling croma filtering for 444 source?

[David Battistella]

Are you watching the clips in FCP? or

only Quicktime.


I set up render preset for each codec. Put a clip in the timeline (about a second or so). render to each codec.

Open all of the clips in FCP and look at the waveform monitor in FCP. In my tests 422 (HQ) and LT were displaying "correct gamma", everything else was like shooting dice at a table in vegas. No continuity at all in QuickTime. I wish they would do a version called QT broadcast or something so that all these gamma standards could be sorted out between codecs.

David

[Johnny Friday]

Are you watching the clips in FCP? or

only Quicktime.


I set up render preset for each codec. Put a clip in the timeline (about a second or so). render to each codec.

Open all of the clips in FCP and look at the waveform monitor in FCP. In my tests 422 (HQ) and LT were displaying "correct gamma", everything else was like shooting dice at a table in vegas. No continuity at all in QuickTime. I wish they would do a version called QT broadcast or something so that all these gamma standards could be sorted out between codecs.

David


I was actually looking at them in Quicktime. BUT that said....they look "slightly" better in FCP. BUT still NOT a representation of the grade that I was doing....so basically a lost effort to even do color in RC-X. I've had better result grading in FCP/Color native R3D's....BUT, the render times are crazy without the rocket.

I have to hope RED will adress this and/or a better software solution will be coming soon with a 3rd party vendor that will utilize the Rocket card and native R3d color correction. Seems it's all right around the corner, but in the meantime i have to resort to this very archaic style of coloring.

[Petri Teittinen]

This may have no bearing on your dilemma, but I figured it won't hurt to report that I'm getting those washed out colours on Windows when exporting to Quicktime with latest two Windows builds.

However, the exports exhibit washed out colours only when I view them on the Quicktime player; colours look fine (and the difference is remarkable) when I play the files on Windows Media Player.

[Chester Lehmann]

I have the same problem exporting to ProRes 4444, but only some times!
- When I export one clip after an other, using the same clip setting and the same export setting for each clip, some clips renders washed out and some not.
- If I select several clips and render them all at once all will wash out or all will not, depending on how the first is rendered the others will look the same (washed out blacks or correct blacks).

I use Leopard on Mac Pro 8 Cores, RedCine X Build 221, Quicktime 7.6.6, have not installed Quicktime 4.1 Plugin

[Johnny Friday]

I've not tried with the old QT component. But probably you're getting "non washed out" results because you are not using the new QT component

[jimhare]

in my experience they have always been washed out... I have routinely added back contrast and sometimes saturation on all clips from the start.

[AlvisZ]

I think it's QuicktimePro bug, since regular Quicktime player opens files more saturated. And even if I export that washed out mov to .tga from QuicktimePro it turns back right (good contrast and saturation)So as in FinalCut timeline. Actually it's strange that Apple dare to call it Quicktime PRO! We shouldn't doubt that everything is correct with files that we open in that PRO player as we just ask our clients money for them!!!

[AlvisZ]

So I'm not sure how will this clip look in real world.
Here's the comparison:

[Johnny Friday]

not only does it occur with QT Pro, but also with the new Quicktime X.

[Chris Kenny]

I don't think this is just a QuickTime Player issue. I'm pretty sure I'm also seeing this with ProRes 4444 transcodes on external monitoring when comparing 10-bit output from RCX via Rocket to 10-bit output form Final Cut via a Decklink Extreme HD. (Monitoring on Dreamcolor in Rec. 709 via HD-SDI and Hi5 converter.) Tried gamma setting at both 'None' and 'Automatic' -- they appear to produce identical files.

Will run some tests with ProRes 422 HQ.

Edit: also see this with 422 HQ.

[Johnny Friday]

I don't think this is just a QuickTime Player issue. I'm pretty sure I'm also seeing this with ProRes 4444 transcodes on external monitoring when comparing 10-bit output from RCX via Rocket to 10-bit output form Final Cut via a Decklink Extreme HD. (Monitoring on Dreamcolor in Rec. 709 via HD-SDI and Hi5 converter.) Tried gamma setting at both 'None' and 'Automatic' -- they appear to produce identical files.

Will run some tests with ProRes 422 HQ.

Edit: also see this with 422 HQ.

I've done every prores transcode and all are washed out. BUT, when i go back to Redcine v20....the prores transcodes DO NOT turn out washed out. So, my non-scientific conclusion is that there may be some REDCODE QT COMPONENT issues that have not yet been resolved with the new color science etc....purely a guess on my part, but seems logical based on my 3 days of testing and testing.

[Dave Dessel]

I consistently get washed out results with build 221. I took the same raw file (shot with build 20), and loaded into the old RedCine and it rendered fine to ProRes. I am guessing that on my machine there is a problem with build 221 as nothing even renders close to what is on the histogram or the preview.

I've also tried a number of new and old Red codecs and nothing makes a difference. None the less, when RedCine-X comes out of beta it's going to be a fantastic tool.

In the meantime, I'll be sticking with Apple Color and the new Beta Plug-In until things change. The waveform vector scope and secondary capabilities provide consistent results.

-DD

[Kaku Ito]

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.

[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:

http://harebrained.com.au/alist/4444test.jpg
(http://harebrained.com.au/alist/4444test.jpg)

[Mike Gross]

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.


Is that with FCP compatibility flag on or off?
What gamma is your monitor set to?
What OS version are you running?
Did you setup the codec with auto or none?

[David Battistella]

@jimhare.

Right. It;s no problem if you know about it, but it is pretty hard to explain if you are shipping it off to another client.

David

[Johnny Friday]

In my personsal case.....the QT prores version is HORRIBLE! Shooting underwater and having even the slightest bit of desaturation RUINS the image for my client. They don't care at all that it may be a software glitch. They merely want a crisp clean image for their film/doc. Otherwise they buy from another shooter usually shooting the Sony 900, Pani HVX200 or Sony EX1.

My clients merely want a clean prores deliverable and don't much care for an R3D file. I of course like the R3d for my stock, but cannot convince my client that the washed out image they are buying really is a clean looking and nice image. All they care about is WYSIWYG. Therefore putting me in the position of having to shoot with my Panasonic or Sony in many cases because i have no solution for delivering a clean prores 4444 or 422.

PLEASE a FiX. OR ....please RED, some official word on how to get to a clean deliverable when outputting from RCX.

[Johnny Friday]

Is that with FCP compatibility flag on or off?
What gamma is your monitor set to?
What OS version are you running?
Did you setup the codec with auto or none?


Mike, that's been covered many times and the end result is still a desaturated image. UNLESS you have some magic you wish to share. But does not seem to matter with codec set to auto or none---same result and latest OS etc.... And where are you setting FCP compatibilty mode? is that in QT 7 ? ---i don't believe an RCX function. But none-the-less, you can play with almost any output settings and the end result is going to be the same. You don't get what you see in RCX. And to color and not get what you see IS A BIG PROBLEM.

[Johnny Friday]

I might add that from the looks of it, most redusers seem to be working on either features, indi's or commercials and they look at dailies and often can work around this desaturation problem because they will ship it off to someone that will fix it and give them the look they want.

some of us will shoot for stock and sell stock so we have to have a clean, beautiful looking image for sale. In my case this is 50% of what i do. I shoot stock and am unacustomed to coloring a clip and not getting what i saw in transcode. And my stock agency will not even show a client one of these desaturated prores transcodes.

so there is obviously a clear need to give some attention to this problem. Looks great on camera and then in RCX, but that does me NOT ONE BIT OF GOOD if i can't print that and deliver it.

[Mike Gross]

Mike, that's been covered many times and the end result is still a desaturated image. UNLESS you have some magic you wish to share. But does not seem to matter with codec set to auto or none---same result and latest OS etc.... And where are you setting FCP compatibilty mode? is that in QT 7 ? ---i don't believe an RCX function. But none-the-less, you can play with almost any output settings and the end result is going to be the same. You don't get what you see in RCX. And to color and not get what you see IS A BIG PROBLEM.

John, trying to help but without getting the info I asked for before or screenshots, you're not being very constructive.

As for magic that works for me all the time:
OSX 10.6.2
QT Player 7.6.3 (FCP compatibility on)
RCX 221
Prores 444 export with gamma correction set to none

screenshot:
7151
bigger:
7150

[jimhare]

Hi Mike,

To me, your QT and RCX images look different and exhibit the same symptoms we're talking about. The QuickTime is slightly washed and has a yellow tint compared to the RCX.

Try some brighter images to make the differences really stand out.

Regarding my test -

Compatibility = on
Gamma = 1.8
ProRes gamma correction = none

[jimhare]

Hi John,

I hear you and agree completely. In your circumstance, perhaps you would be better to export DPX or uncompressed and then make your ProRes in After Effects or maybe even Compressor.

At least you wouldn't have to explain yourself to clients about it.

Jim


Looks great on camera and then in RCX, but that does me NOT ONE BIT OF GOOD if i can't print that and deliver it.

[Chris Kenny]

I think the reason that this problem is so hard to figure out is that there are multiple effects to sort out. For instance, there is undoubtably some QuickTime strangeness. On this machine (my laptop) I'm running 10.6.3, FCP 7.0.2 and QT Player 7.6.6 w/ FCS color compatibility enabled. ProRes 4444 with gamma correction set to 'None' matches what I see in RCX exactly in QT Player. On the other hand, transcodes to ProRes 422 HQ (otherwise the same settings) look washed out in QT Player. But then when I jump to FCP, both the ProRes 422 HQ and the ProRes 4444 look identical, and both match RCX.

Meanwhile, on our main transcoding machine at work, I'll occasionally transcode a batch of clips to ProRes 4444 via RCX/RedRocket and find that not only do they not match what I see in RCX (via either internal or external monitoring of HD-SDI), but they're so washed out as to be obviously just wrong; much worse than the QT Player ProRes 422 HQ issues I see with the software transcode on my laptop. Then later I might transcode the same clip again, and it will look fine (or at least not as obviously wrong; I haven't checked closely enough to see if there's some subtle shift).

I'm pretty sure this second thing is a different issue from any QuickTime-related gamma strangeness, and that's it's a bug in either RCX or with the Rocket.

[Mike Gross]

Hi Mike,

To me, your QT and RCX images look different and exhibit the same symptoms we're talking about. The QuickTime is slightly washed and has a yellow tint compared to the RCX.

Try some brighter images to make the differences really stand out.

Regarding my test -

Compatibility = on
Gamma = 1.8
ProRes gamma correction = none

I chose a darker images because gamma shows bigger differences there.

Also, I overlaid the two images in photoshop and checked with color checker and they are pretty much identical (within one number). Given that Quicktime is changing the colors for display, that's expected. As well as one going through compression and the other is not.

[jimhare]

Given that Quicktime is changing the colors for display, that's expected.

Isn't that what we're talking about? The fact that QuickTime is changing the colors?

I have no doubt the files are being written with accurate color info, but it's being bastardized as it goes down the line, requiring compensation to bring it back.

What we need is a way to get our files to look the same in FCP as they do in RCX. Anything else is academic.

[Gunleik Groven]

Isn't that what we're talking about? The fact that QuickTime is changing the colors?

I have no doubt the files are being written with accurate color info, but it's being bastardized as it goes down the line, requiring compensation to bring it back.

What we need is a way to get our files to look the same in FCP as they do in RCX. Anything else is academic.

And the way to do that, without distorting the signal, would be to set up the display in a way that emulates the FCP display.

Any other solution will interfer with the signal.

It's called a LUT, but as not all displays accepts LUTs, you may werll do a ballpaky calibration...

[Mike Gross]

Isn't that what we're talking about? The fact that QuickTime is changing the colors?

I have no doubt the files are being written with accurate color info, but it's being bastardized as it goes down the line, requiring compensation to bring it back.

What we need is a way to get our files to look the same in FCP as they do in RCX. Anything else is academic.

If you overlay the two images in photoshop, you can see that the images are essentially the same. If you're saying that a 1 number difference is too much, then even DPX will not work for you because the display is 8bit.

Compression will affect the colors as in the pixel in might not be exactly the same pixel out.

Each codec can do it's own conversion from RGB to YUV. This will also affect colors.

The worst offending piece is that each application in the apple world (QT player 7, QT player X, FCP) will interpret the footage depending on what it thinks the intention is based on the source. It then adjusts the gamma. Take the same clip into all three apps and they will display different gammas because it's making assumptions and changing gammas. Output a tiff from QTplayer, and it'll be different (like RCX in the cases where the gamma is changed more extremely).

[Eric Haase]

I think the reason that this problem is so hard to figure out is that there are multiple effects to sort out. For instance, there is undoubtably some QuickTime strangeness. On this machine (my laptop) I'm running 10.6.3, FCP 7.0.2 and QT Player 7.6.6 w/ FCS color compatibility enabled. ProRes 4444 with gamma correction set to 'None' matches what I see in RCX exactly in QT Player. On the other hand, transcodes to ProRes 422 HQ (otherwise the same settings) look washed out in QT Player. But then when I jump to FCP, both the ProRes 422 HQ and the ProRes 4444 look identical, and both match RCX.

Meanwhile, on our main transcoding machine at work, I'll occasionally transcode a batch of clips to ProRes 4444 via RCX/RedRocket and find that not only do they not match what I see in RCX (via either internal or external monitoring of HD-SDI), but they're so washed out as to be obviously just wrong; much worse than the QT Player ProRes 422 HQ issues I see with the software transcode on my laptop. Then later I might transcode the same clip again, and it will look fine (or at least not as obviously wrong; I haven't checked closely enough to see if there's some subtle shift).

I'm pretty sure this second thing is a different issue from any QuickTime-related gamma strangeness, and that's it's a bug in either RCX or with the Rocket.
Ive seen the same issue where footage transcodes was obviously processed wrong. Once retranscoded, it would look correct. Looked to be some sort of rcx bug. As if the color grade didn't take the first time around. Set us back a few hours each day on set transcoding. That, along with the frequent crashes were enough to drive our Dit crazy although he worked hard and stayed focused despite the problems.

[jimhare]

@ Gunleik - Good advice. I was avoiding the term LUT because my monitor won't take one! I'm thinking of creating a monitor setting that matches FCP to RCX and using that to grade on. As you say, ballparky may be as close as we get.

@ Mike - I don't mean to argue, all I'm saying is I'm getting about the same amount of difference you are between RCX and QT, and I don't think it's close enough. I also understand the reasons why. But this thread is about coming up with a working solution and we need to stay focused on that goal.

----------

So collectively are we thinking that adjusting the FCP screen to closely match the RCX screen and create a LUT (or ballparky monitor setting) to use with RCX is the best way forward for the time being?

If so, what's the best way to do this to have any hope for consistent results? Shoot a chart and run it through? Or just as few good examples of real world footage and fine tune it?

[Mike Gross]

@ Gunleik - Good advice. I was avoiding the term LUT because my monitor won't take one! I'm thinking of creating a monitor setting that matches FCP to RCX and using that to grade on. As you say, ballparky may be as close as we get.

@ Mike - I don't mean to argue, all I'm saying is I'm getting about the same amount of difference you are between RCX and QT, and I don't think it's close enough. I also understand the reasons why. But this thread is about coming up with a working solution and we need to stay focused on that goal.


Unless it's exactly 100% the same pixel how it could get much closer? Creating a lut, etc wouldn't get you any closer. If you look at the two images I posted and over lay them in photoshop, they really are only one number difference between the two. For example I got 182,150,73 on the quicktime and 182,150,74 on the screenshot from RCX for the pixels. What's close enough mean? You're going from uncompressed 8 bits RGB on the monitor to a 10bit DCT compression in prores so it has to change the numbers a bit.

[Gunleik Groven]

Mike. I see your logic, but it doesn't help when the images are visibly and undeniably seen as different.
If these measurements are from linear image data, I can see how they happened. In this case I choose to trust my eyes... -:) And I do see significant difference in Jims images...

In my case it was basically NOT too serious. different softwareversions created most of the trouble (we're not snow leopard guys over here... Hardly leopard! -:)) A couple of software updates on one of the computers took care of a lot of the issue.

The rest I'll sort out by setting my own monitors at lower contrast, and a bit brighter.

It's ballparky. But this is for prores 1080 offline files. ( -:) )
We can live with that.

Actually plays out pretty nice...

As to "How to do this"

Get some kind of test-image that involves a lot of colors and levels in RAW. A mabeth would be cool. The ones I have posted works magic...

Make an adjustment in your reference application, and set up monitor profiles that make it look identical/as similar as you can manage in the other applications...

I would guess a FCP SDI output OR Color SDI output would be good reference points... (though these two may very well NOT be similar...)

Make your choice from the final point, not the initial...

[Mike Gross]

Mike. I see your logic, but it doesn't help when the images are visibly and undeniably seen as different.
If these measurements are from linear image data, I can see how they happened. In this case I choose to trust my eyes... -:) And I do see significant difference in Jims images...

How can be seeing visibly and undeniably different apply when the screenshots look 99.5% the same?

Of course there is a difference in jims images because it's probably not using the same path as what I'm doing. I thought the point was to show how to do it so there isn't a problem, not to prove that because there's a way to get a mismatch, that there's no way to do it properly.

If I can get a 99.5% match, it's that acceptable (I think it is given the compression involved otherwise we'd be talking uncompressed and 8bit) and can someone else replicate with the same settings as me. Because for me it works all the time in my setup.

[Gunleik Groven]

Good.

As I said, my issues turned out to be rather minor...

But it is a problem when the images look too different, like in Jims example... -:)

[Nick Shaw]

I think there is some talking at cross purposes going on here. I think Mike is saying that the images in his example match (which they appear to do to me) and others appear to think he is saying that Jim's images match (which clearly they do not).

[Gunleik Groven]

yup.

I am looking at Jims images...

[Sanjin Jukic]

Here there are my examples:

http://homepage.mac.com/sanjinjukic/RED/Bird_flower_RX221.jpg
Detail from REDCINE-X 221 with player and image control parameters,...also shot on R1 with AF Nikkor 80-200mm f/2.8 D, manual ED zoom, no filters.

http://homepage.mac.com/sanjinjukic/RED/Bird_flower_MX_PR4444.jpg
Look like it's appropriate but really not 100%: Color corrected and exported from REDCINE-X-221 @ Apple ProRes 4444 1K resized, Depth: Millions of color, Gamma Correction: None.

http://homepage.mac.com/sanjinjukic/RED/Bird_flower_MX_H264.jpg
It looks washed: Color corrected and exported from REDCINE-X-221 @ H264 1K resized, muli-pass, best compression.

[Johnny Friday]

I think there is some talking at cross purposes going on here. I think Mike is saying that the images in his example match (which they appear to do to me) and others appear to think he is saying that Jim's images match (which clearly they do not).

I think to share images on this web....as small as the size limits are...will make it difficult to see those details that each of us sees. But the fact remains that there are differences and if we cannot get to Z from A without some hacking around, then clearly some effort should be put to fix this problem. I don't see how it can be a QT problem since it was not an issue prior to the new color science. That said, i know everyone here has a vested interest in seeing that we can easily go from RCX to any codec and expect with accuracy to get what we see in RCX depicted in Prores or other codecs.


EDIT: i see Sanjin's images weighed in now...and there CLEARLY is a difference with those images.

[Johnny Friday]

John, trying to help but without getting the info I asked for before or screenshots, you're not being very constructive.

As for magic that works for me all the time:
OSX 10.6.2
QT Player 7.6.3 (FCP compatibility on)
RCX 221
Prores 444 export with gamma correction set to none

screenshot:
7151
bigger:
7150

Mike...sorry if i came across as gruff. I've been at this for 3 days last month and was very dissatisfied with coming up empty handed and no solution. I'd have to go back into some clips and make pics again to show what i am seeing. But did not want to put the time again as i've wasted so much already and i think everyone agrees there is a clear difference. Much depends on how much contrast you have in the image. Much of my u/w footage EXAGERATES this effect so it's not a slight shift in the colors for me.

I think Sanjin's images sum up the problem perfectly. if required and it would help to get a fix, i'd go back and do the same and post images. But RED has posted here a few times....Deanan and they seem to think it's a QT problem. So if that's the case, how can we then proceed from RCX to a proper rendition of a prores 4444 ? what is the workaround? Or is a fix coming? Basically i can't shoot and send prores files like this to clients nor do i have the time to continually work the images to get the proper colors via many workarounds...I'd say im waiting for RED and Apple to come up with a solution. But cant wait a year.

***that is if it in fact is a QT issue. But for the moment i have a hard time swallowing that it is as I've had only problems since new color science was instituted.....AND I LOVE the new color science by the way....and FLUT---but want it all to work and properly transcode what I see on RCX and R3d's to Prores. The washout effect when transcoding is a KILLER for shooters in the field sending back Prores for edit for natural history documentaries where budgets are slim and coloring and rough editing are often left to the shooter in the field.---the only exception is if you work for the BBC and budgets are of not much concern for color/editing. But that's the only time that comes into play.

[Dave Dessel]

I too am a member of the Washed-Out-Club. I took some footage shot with build 20 and rendered it out with the old Red Cine to ProRes - no issues at all.

Then I took the same file inside RedCine-X, rendered to ProRes and got the washed out result.

I've been using Apple Color with the latest beta plug-in, referencing scopes and waveforms and the results are great. This is fine for in-house projects, but delivering ProRes directly to a client after a shoot is not easy.

No disrespect meant to folks at Red as I am sure this will be solved.

-DD

[Jeff Kilgroe]

I don't know anyone who DOES NOT have this problem with X221. I'm sure RED is working on it, it's a beta, after all...

[Johnny Friday]

I don't know anyone who DOES NOT have this problem with X221. I'm sure RED is working on it, it's a beta, after all...

Jeff, if you look at earlier posts from Deanan. RED claims it is an Apple QT issue, but many of us don't think it is.....so we need to keep the pipeline going to RED as it certainly does not appear to be a QT issue and we all hope RED will put some effort into this as it is part of many of our workflows. It is a pure waste of time to grade on RCX if you are transcoding to Prores or (as i hear) even other codecs using new color science, FLUT etc....

[David Battistella]

I don't know anyone who DOES NOT have this problem with X221. I'm sure RED is working on it, it's a beta, after all...

Jeff, if you look at earlier posts from Deanan. RED claims it is an Apple QT issue, but many of us don't think it is.....so we need to keep the pipeline going to RED as it certainly does not appear to be a QT issue and we all hope RED will put some effort into this as it is part of many of our workflows. It is a pure waste of time to grade on RCX if you are transcoding to Prores or (as i hear) even other codecs using new color science, FLUT etc....

It's a QT issue in the sense that you may hand off certain gamma values to a codec, but that is not what gets rendered. If there is no documentation or methodology to how to feed certain codecs how can RED go through each codec and figure out the gamma and color issues?

Also, to further complicate matters QT will set the gamma by itself depending on what application is wanting to play back the file.

This is the stressor because I do not believe that this is high on the Apple "todo" list and probably less so lately.

David

[Jeff Kilgroe]

Jeff, if you look at earlier posts from Deanan. RED claims it is an Apple QT issue, but many of us don't think it is.....so we need to keep the pipeline going to RED as it certainly does not appear to be a QT issue and we all hope RED will put some effort into this as it is part of many of our workflows. It is a pure waste of time to grade on RCX if you are transcoding to Prores or (as i hear) even other codecs using new color science, FLUT etc....

It is a QT issue as far as I can tell too, but it seems that X221 is giving different results going to QT than the previous build 194 or whatever I was using before and that wasn't right either. That said, it's not affecting me or my workflow. I know what I'm going to get and work accordingly. I don't do much for color correction work within RCX anyway. Lateley, my workflow is R3D in, transcode to ProRes 4x4 @ 4K and I online with 4K files. Yes, really, works pretty good for most of my projects that are rather short anyway.

I haven't installed the new update to CS5 for "more layers" or whatever it's supposed to give and it seems there's an updated plugin about to be released for RED support, but I haven't really used CS5 for any real project just yet. Maybe soon here. Everything I have in the works was already in progress under FCS when I received my CS5 anyway...

[Kaku Ito]

Hey guys, I will work on Media Composer 5, too, so let you know how that goes.

[Chris Parker]

this is probably a dumb question, but have you tried rendering out the same look from RocketCine-X? say build 1740? or 1720? are the results the exact same?

[jimhare]

Good news everybody! The new RedCine X build 246 finally matches when it transcodes to ProRes4444!

Looks the same in QT as it does in the RCX, and looks the same in FCP!

Yep, no more washed out QT files, it's like a 98% match, which is more than close enough for me!

Great day!

QT Pro 7.6.6
RCX 246
Red Rocket

[Johnny Friday]

Good news everybody! The new RedCine X build 246 finally matches when it transcodes to ProRes4444!

Looks the same in QT as it does in the RCX, and looks the same in FCP!

Yep, no more washed out QT files, it's like a 98% match, which is more than close enough for me!

Great day!

QT Pro 7.6.6
RCX 246
Red Rocket

GREAT NEWS!! Going now to look for the download. AND, glad that we all stuck this out till the end and informed RED of this problem as we now have a solution...i hope.

[Johnny Friday]

Jim,
where is the download? can't find it on red support. Looking through reduser now.

[David Battistella]

this is probably a dumb question, but have you tried rendering out the same look from RocketCine-X? say build 1740? or 1720? are the results the exact same?

Chris,

Many of these issues occur in Rocketcine -X as well depending on which codec you are rendering to. You or Jesse can do some tests with DVCPRO HD and see the problem.

Daivd

[Johnny Friday]

Good news everybody! The new RedCine X build 246 finally matches when it transcodes to ProRes4444!

Looks the same in QT as it does in the RCX, and looks the same in FCP!

Yep, no more washed out QT files, it's like a 98% match, which is more than close enough for me!

Great day!

QT Pro 7.6.6
RCX 246
Red Rocket

Can't find any links or any information to a REDCINE-X build 246 anywhere on REDUSER. ????

[Uli Plank]

Get used to Crucial Ordnance:

http://www.reduser.net/forum/showthread.php?p=610777#post610777

[Johnny Friday]

Get used to Crucial Ordnance:

http://www.reduser.net/forum/showthread.php?p=610777#post610777

Does anyone know if the new build 246 requires a new QT codec manual upgrade? or will this new build 246 replace the older (Beta 4.1) with a new version?

[Kaku Ito]

REDLINE is a command line and doesn't include the QT codec.

My understanding is that QT codec is for translating R3D within QT to display R3D via proxies with QT based apps like QuickTime player and FCP (when they playback R3D with proxies in realtime).

The REDLINE access the command line to render R3D.

So long story short, I don't think REDLINE build 246 does not replace the Beta 4.1 QT codec.

[Johnny Friday]

REDLINE is a command line and doesn't include the QT codec.

My understanding is that QT codec is for translating R3D within QT to display R3D via proxies with QT based apps like QuickTime player and FCP (when they playback R3D with proxies in realtime).

The REDLINE access the command line to render R3D.

So long story short, I don't think REDLINE build 246 does not replace the Beta 4.1 QT codec.

Kaku,
i was referring to Redcine-x 246 build---if we had to install a new QT codec--like with Redcine-x 221 or whatever the last build was.....i was not actually referring to Redline.

[Johnny Friday]

I thought i'd revive this thread.....since this is STILL the case...RCX images look great IN RCX, but transcode out to Prores and you get washed out images.....I've learned to live with it and actually go to another color grade program. but too bad we don't have WYSIWYG out of this.





Good news everybody! The new RedCine X build 246 finally matches when it transcodes to ProRes4444!

Looks the same in QT as it does in the RCX, and looks the same in FCP!

Yep, no more washed out QT files, it's like a 98% match, which is more than close enough for me!

Great day!

QT Pro 7.6.6
RCX 246
Red Rocket

[BigLu]

Now this might be in the thread somewhere its 13 pages long and im not gonna look.

Are you making sure to click Gamma Correction to NONE?
and it still does a washed out look?

[Johnny Friday]

Definitely Lu....tried every which way but loose...just seems to be nature of going to prores. but these are slight slight differences....I find most folks don't notice.

[David Ibbitson]

Hi Johnny,

As you know the gamma issue is well known and documented, but as has been mentioned in this thread, RCX, QT7 and FCP7 should all match. Indeed, I just retried it myself and confirmed. 1920x1080 Prores 422. Can you verify this case?

Edit: I should also mention I'm viewing everything on the same monitor, no Red Rocket.

Thanks,
David

[Johnny Friday]

HI David,
For me and a few other underwater film guys....this has been a constant bother. No WYSIWYG....we can get the image looking beautiful; tack sharp and pleasing with colors in RCX, but transcode out to prores 4444 or 422 and we get de-saturated and not such sharp images. I'm running off of a RR card and the other film-maker I know is NOt using a RR card---we BOTH get same results.....and both of us are using different systems to monitor colors.....so we're not seeing the same issue from the same corner of the street. I find that in order to get the image to work well i have to take it to FCP or COLOR and (the prores file) and work on it to get WYSIWYG. I WISH this was not the case and i've seen it all to often. Underwater we can really see this......Glad to post images of how this works.....i believe back in this thread i had done so....however they are just compressed uploads.

[Matthew Love]

I know this is an old thread but I've been experiencing this as well.. below i'll attach a screen grab. Total change right?

I then stopped playing the transcodes in quicktim (10 currently) and started using VLC and things looked more like I had originally graded them.

So I'm assuming this is a weird redcine/quicktime thing or maybe more on quicktimes end.

again, VLC gave me the proper look.

blow is a redcine/quicktime comparison

[BRANDON JAMESON]

I have the same problem....

[M Most]

I have the same problem....

Have you looked at them using Quicktime 7 player?

[BRANDON JAMESON]

yes and also in Avid.

[Björn Benckert]

It's the new OSX thing no?
Apple has taken quicktime to yet a new level of mystery. It's like no matter what you do with QT you will for sure end up with the wrong gamma. As I understand it's their change form 1.8 to 2.2 gamma that messes everything up.

Before I could export a uncompressed qt from my flame it would be identical on a mac.... latest osx installed, then not so much the gamma is pushed down what looks to be a setting that tries to look at the file as gamma 2.2 when it's actually 1.8....

[Johnny Friday]

It's the new OSX thing no?
Apple has taken quicktime to yet a new level of mystery. It's like no matter what you do with QT you will for sure end up with the wrong gamma. As I understand it's their change form 1.8 to 2.2 gamma that messes everything up.

Before I could export a uncompressed qt from my flame it would be identical on a mac.... latest osx installed, then not so much the gamma is pushed down what looks to be a setting that tries to look at the file as gamma 2.2 when it's actually 1.8....

Well, i've been experiencing this from day one (2007) with the first trancodes out of not redcine, but the program before that. You can do anything you want in the settings such as choose none or auto for gamma settings in RCX, but no matter what you do, transcode to Tiff, QT, Prores whatever you get a washed out desaturated look. After having an experienced colorist look at it, his assessment was that it was a RCX transcode engine issue. For whatever reason, using RCX will not give you color accurate to prores or as i've found out even to tiff and DPX---well, i've never gotten it to be color accurate. BUT, when taking same into Resolve, i can get accurate transcodes Oh....Even in Apple Color it's accurate. This is very disappointing that we have had to live with this for as many years in that RCX COULD be a great one light transcode tool, but i've found after spending hours and hours grading in RCX and then transcoding---it was all for nothing....and very disappointing to waste all that time.

[Gunleik Groven]

Color is/was not accurate. But that is a different story...

[Björn Benckert]

Well, i've been experiencing this from day one (2007) with the first trancodes out of not redcine, but the program before that. You can do anything you want in the settings such as choose none or auto for gamma settings in RCX, but no matter what you do, transcode to Tiff, QT, Prores whatever you get a washed out desaturated look. After having an experienced colorist look at it, his assessment was that it was a RCX transcode engine issue. For whatever reason, using RCX will not give you color accurate to prores or as i've found out even to tiff and DPX---well, i've never gotten it to be color accurate. BUT, when taking same into Resolve, i can get accurate transcodes Oh....Even in Apple Color it's accurate. This is very disappointing that we have had to live with this for as many years in that RCX COULD be a great one light transcode tool, but i've found after spending hours and hours grading in RCX and then transcoding---it was all for nothing....and very disappointing to waste all that time.

If make a screendump with RCXP open I get same color as my tif renders.... if I'm not completely mistaken.

[Johnny Friday]

Well, i could get exact WYSIWYG from Color.....when transcoding to Prores for my stock. RCX a nightmare in that nothing every comes out as colored in the monitor. that said, i'm coloring individual clips for stock agency and have tried numerous software--color for me works very well...Resolve better. Can't tell you how many times i have been back and forth on this and comparing with guys like Howard Hall who experiences the exact same issues and is now i think back to using colo again.


Color is/was not accurate. But that is a different story...

[Johnny Friday]

If make a screendump with RCXP open I get same color as my tif renders.... if I'm not completely mistaken.

Bjorn, what is a screendump? and RCXP ? do you mean using premier and the raw tools?---that what you mean with RCXP ?

[Ces Peynetti]

I've always had the same issue trying to open the files on QT X, and even used to happen with QT 7. Then one day, it stopped happening, which made me happy. Later on I did an OSX update and went back to washed out colors. Was a bit frustrating but found a preference on QT7: "Enable Final Cut Studio" color compatibility. Enabling this brought my clips colors back to normal. At least on QT 7. Make sure you have this enabled. If you do and you still have the same results, then it really is a head-scratcher.