Welcome to our community

Be a part of something great, join today!

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

Gamma shift in Color? the solution...

Sorry for late replay, I missed this one.

If you are outputting R3D native files as DPX from Color, you would want to only "look" with 1.226 applied but don't apply upon rendering. This is because Color takes RGB material as 1.8 gamma then output as 2.22. Contrary, in case of handing R3D in Color then output as QT, then you need to apply the master gamma of 1.226 since Color tries to output as gamma 1.8, thus your material would be matched to 2.22.

Wow, this makes my head spin. A companion program, like Color is to FCP, should not have hoops to jump through like this. Sure hope things are more streamlined in Final Cut Suite 3. Also, in Red's own instructions on this workflow I didn't see any mention of this gamma bug- or did I just miss it?
 
This is not a bug, it is how they made it. I heard that Color was made as Final Touch, which basically supported DPX mainly. So, it was made to support DPX and Apple acquired it then added more quicktime support. So the adoption is partially made at this point and like you said, it should be improved in FCS3.
 
This is not a bug, it is how they made it. I heard that Color was made as Final Touch, which basically supported DPX mainly. So, it was made to support DPX and Apple acquired it then added more quicktime support.

Almost everything in Final Cut Studio was developed by others and acquired by Apple. Final Cut Pro was developed by some ex-Adobe people at Macromedia (as a cross platform product, by the way), and acquired by Apple before it was released. Apple killed the Windows version and released the Mac version as Final Cut Pro. Cinema Tools was written by the folks at Digital Film Tree and bought by Apple. DVD Studio Pro was based on a program called DVD Director by a company called Astarte, and enhanced with technology Apple gained when they bought Spruce Technologies. Soundtrack Pro and Motion were developed by Apple, but Motion in particular was primarily done by a team of programmers who had developed large parts of Combustion but were let go by Autodesk in the Discreet takeover, along with some technology Apple acquired when they bought Silicon Grail. Shake (not technically part of Final Cut Studio, of course) was acquired when Apple bought Nothing Real, its developer.

While Apple has a great knack for user interfaces, and a good ability to package things in an attractive way, the pro apps are largely products that were acquired from others, hence one reason why integration between them has always been problematic (unlike Adobe, which has developed almost all of their products themselves with the notable exception of After Effects, which they got years ago in an acquisition of COSA).
 
Almost everything in Final Cut Studio was developed by others and acquired by Apple. Final Cut Pro was developed by some ex-Adobe people at Macromedia (as a cross platform product, by the way), and acquired by Apple before it was released. Apple killed the Windows version and released the Mac version as Final Cut Pro. Cinema Tools was written by the folks at Digital Film Tree and bought by Apple. DVD Studio Pro was based on a program called DVD Director by a company called Astarte, and enhanced with technology Apple gained when they bought Spruce Technologies. Soundtrack Pro and Motion were developed by Apple, but Motion in particular was primarily done by a team of programmers who had developed large parts of Combustion but were let go by Autodesk in the Discreet takeover, along with some technology Apple acquired when they bought Silicon Grail. Shake (not technically part of Final Cut Studio, of course) was acquired when Apple bought Nothing Real, its developer.

While Apple has a great knack for user interfaces, and a good ability to package things in an attractive way, the pro apps are largely products that were acquired from others, hence one reason why integration between them has always been problematic (unlike Adobe, which has developed almost all of their products themselves with the notable exception of After Effects, which they got years ago in an acquisition of COSA).

So what's your point towards the original topic?
 
So what's your point towards the original topic?

I'm just providing a bit of background information as to why the integration between the programs is somewhat incomplete. What's your problem with that?
 
Out of all the phone manufacturing companies out there like Nokia, Blackberry etc. Apple definitely have the best editing application ...............> runs away.....>
 
Hello, I need your help. It is related to gamma shift, but different issue. It might not be an issue, and maybe just the normal behaviour.

I am working on a project with a lot of compositing in AE. I was exporting each sequence as Prores HQ. I have an MXO2. When I export the Prores from AE and bring them into Color, on my MXO2 output in Color it looks pretty much the same as the output of the MXO2 in AE's composition viewer.

But now, since my Ae sometimes crashes while rendering I decided to export Tiff sequences 16bit. Now the problem with these sequence (I'll try with another ones to see if it is only with this one or it is a normal habit) is that when I export the tiff sequence and I import it into Color, it completely crashes the histogram. It brings down the whole histogram way below my 0 point. I can play with the Gamma and Gain to quite match the Prores HQ export.

Is this a normal issue, considering the Tiff is 16 bit and HQ not or there is something I am doing wrong? It is estrange because if I re-export the tiff sequence from quicktime as a Pro Res, then in COlor works fine. It seems that it is a Tiff sequence issue. I dont understand it.

Thanks
 
Tiff on mac is usually generated as gamma 1.8, so makes the material look brighter.
If you are going back and forth between RGB and YUV material and using something like MXO2 that does not have LUT capability, then you'd have to apply multiplier in the master gamma in color. So, in your case, apply 0.810810810810811v to all of your tiff materials then it will end up in 2.22 gamma. That will be applied when you render as any QT YUV clips.

AE crash issues should be better with AE CS4? More over, Snow Leopard with 64-bit support and future CS4 with 64-bit support? I'm assuming your crash is based on memory issues.
 
Sorry for late replay, I missed this one.

If you are outputting R3D native files as DPX from Color, you would want to only "look" with 1.226 applied but don't apply upon rendering. This is because Color takes RGB material as 1.8 gamma then output as 2.22. Contrary, in case of handing R3D in Color then output as QT, then you need to apply the master gamma of 1.226 since Color tries to output as gamma 1.8, thus your material would be matched to 2.22.

Thanks Kaku for the information, but I am getting all confused here. My understanding was that Color uses 2.2 gamma. So I set up my computer as 2.2 gamma. Grade in Color, basically using the MXO2 monitor output, but the viewer in the color viewer should be similar to the MXO2 output. Of course it is not a color monitor, but should be close. So you are saying that even if Color is a 2.2 it is trying to output quicktimes as 1.8?

My understanding was that I just have to grade with Color and the MXO2, then output it to a quicktime. Bring it in Final cut. Everything will look darker, but it is right, because it is calibrated as REC709 with the MXO2. And if I want to see it right in final cut or any Apple quicktime application, I just need to change my Display settings to 1.8, and it will look normal again. But if I want to make a DVD or export a WMV for PC, I would export the clip the way it is even if it looks dark on Final Cut with display at Gama 2.2. Am i missing something? I am getting quite lost here. I think I need to go and search again on all the Gamma threads again and study hard.

"Imagine there's no Gama 1.8
It isn't hard to do
Nothing to kill or die for
And no PAL-NTSC too
Imagine all the people
Living Color-correcting time in peace

You may say that I'm a dreamer
But I'm not the only one
I hope someday you'll join us
And the world will live as one"

John Lennon knew what was talking about. :hippie:

Thanks,

IC
 
How Color treats gamma is different depending on wether the material is RGB or YUV.

First, forget about what you see on computer display at this point. Just concentrate on what's happening on MXO2's output.

If you are grading R3D and your using MXO2 to monitor, then rendering to DPX, you may want to apply 0.810810810810811 in the master gamma (preferably in Primary out) to all of the clips while you are grading, then when you render, clear the 0.810810810810811 value back to the default by resetting in one clip and copy to all (that is why I recommend to do it in Primary out). This is because Color shows R3D or Tiff material as gamma 1.8 as default (even on MXO2 output or Blackmagicdesign output), so you want to "look" as gamma 1.8 being 2.2 then apply 0.810810810810811 in the master gamma in Primary out.

People with Multibridge Pro can apply 1.226 in the LUT (in the control panel output section) then don't have to do anything in the master gamma.

Now, if you are rendering from R3D to QT, then no matter if you are using MXO2 or Multibridge Pro, you would want to apply 0.810810810810811 in master gamma, so you "look" to grade with 1.8 gamma material (since Color treat R3D material that way) being 2.22 gamma and burn that to render to QT, so your QT clips will inherit 2.22 gamma.

Now, I grew up with those songs and totally feel your pain. In Snow Leopard the base gamma will be 2.2 (that is still little off from real HD format being 2.22) but DCI spec. should be at 2.6 gamma. So Snow Leopard might not be the utopia if you are going to be living in the digital cinema world. But at least when the Snow Leopard gets popular, we can keep the web material at 2.2 gamma, instead of targeting at gamma 2.0 which is in between Windows (2.2) and legacy Mac (1.8). I do notice some of the coded with QT are treated as 2.2 even at this point though.
 
???

???

Kaku thanks a lot for your patience and time. I kind of understand it but not really yet. And the more I read, I get more confused, and my results are different, so I guess even a "This is for dummies" still sounds advanced to me. I guess I need to clarify few concepts first. Please bare with me as I might ask really stupid questions, this is pretty new to me, and I apologize for this long post.

1. R3d is RGB or YUV?. And how about the proxies?; I assume are the same. So let's say if R3d=RGB then is the same as Tiff or DPX

2. If I get an r3d and render it as a Quicktime Pro Res HQ with FCP or AE it becomes YUV. Is that correct?

3. YUV is always 2.2 gamma?

4. When using MXO2 with either AE or Color, what is the Gamma the Mac should be in for making the Color Viewer and the Compositing window closer to the MXO2 for getting better consistency. Of course not for Color grading, but for having better match between the MXO output and the Mac screen. In my testings I think it looks closer with Rec709 both on Color and AE, but I can't really tell.

Tiff on mac is usually generated as gamma 1.8, so makes the material look brighter.

5. If I export and R3d from AE as a TIFF sequence and import it in Color it looks and has exactly the same histogram as an R3d that I import in Color and set the same settings. I guess that's a good sign.

6. If I export the R3d from AE as ProRes HQ, and import it in Color, it is darker than the Tiff sequences. Pretty much like 1.200750 in the master gamma. So if I put this 1.20 it gets really close to the Tiff sequence.

7.If I bring the Pro REs HQ that I export from AE and bring it in Color the Color MXO2 output, is the same as the R3D sequence MXO2 output in AE. So I guess AE MXO output is always gama 2.2 and Color is only 2.2 when you have YUV content. Is that correct?

If you are going back and forth between RGB and YUV material and using something like MXO2 that does not have LUT capability, then you'd have to apply multiplier in the master gamma in color. So, in your case, apply 1.226 to all of your tiff materials then it will end up in 2.22 gamma. That will be applied when you render as any QT YUV clips.

8. Here I get lost. So I have an R3d clip, next to Tiff Sequence, which have exactly same histogram and have same output in the MXO2 monitor. And then I have the Prores clip (that was rendered from AE), that looks darker.
So if I applied the 1.226 to the Tiff and r3d files they get even brighter. And where that 1.226 number come from? Shouldn't I just put less Gamma. If I put, 0.8027 In master gamma, it gets really close to the Prores HQ file that I rendered from AE.

AE crash issues should be better with AE CS4? I'm assuming your crash is based on memory issues.
Well, I have CS4 and that's another story. Neat image giving problems, Mocha as well and I guess a lot of Ram problems. :head_explode:

This is because Color shows R3D or Tiff material as gamma 1.8 as default (even on MXO2 output or Blackmagicdesign output), so you want to "look" as gamma 1.8 being 2.2 then apply 1.226 in the master gamma in Primary out.[QUOTE/]

So you are saying that when the r3d shows on the MXO2 monitor as 1.8 but it should be 2.2 which is darker or more contrasty. Then I go to Primary out and add 1.226 and it becomes brighter and I start grading in my primary in. I dont understand it.

When my color corrections are done I render it as Prores HQ and becomes 2.2. Bring it into Final cut. Change my System settings to 1.8 gamma. And my clip looks the same as my output of Color in MXO2. And both have the same histogram. And I assume it is Gamma 2.2.

And then you say that If I want to render out some RGB jpegs. (I can't render DPX, don't have the option, I guess I need to buy some third party plugin for that right?) So I go File/Export/Jpeg and right before I do this I reset the Gamma in Primary output (erasing the 1.226). The jpeg I get, well, it is really small, and when I open it in Photoshop is really really Dark, and it says "untagged Rgb 8bpc" profile.

I am doing something wrong. I thought with the MXO2 was just to calibrate it and the world was a happy 2.2 place. I guess I was wrong.

And my last question. What is your advise. To stick with Gamma 2.2 in the Mac and only switch to 1.8 when editing in Final cut?

Thanks so much, and If I ever go to Japan, I will buy you tons of Beer , or Sake :beer:

Ivan C.
 
I haven' tested working in CS4 natively and port it over to Color or FCP, so I'll see what MXO2 is doing in there.

1. R3d is RGB or YUV?. And how about the proxies?; I assume are the same. So let's say if R3d=RGB then is the same as Tiff or DPX

R3D is supposed to be RAW but Color thinks it's not YUV, so it seems to treat it as 1.8.

2. If I get an r3d and render it as a Quicktime Pro Res HQ with FCP or AE it becomes YUV. Is that correct?

FCP switches Macintosh display gamma to 2.2 automatically. For that reason, I would keep the display set to 1.8. So, if you adjust the picture looking through FCP's 2.2 gamma with material handling at 1.8, the output file becomes 1.8. That is the reason why in most cases, FCP material sent to Windows to play, it looks darker. The rendered result sometime differs depending on the codec, so I have to see about your question. I will certainly look into After Effects/MXO2 combination and how it is with Wayne/Matrox. Are you working and talking about ProRes HQ in this case?

3. YUV is always 2.2 gamma?

I don't know if I can say it is 2.2 but most cases in working with 709 standard, it should be set to work with 2.22.

4. When using MXO2 with either AE or Color, what is the Gamma the Mac should be in for making the Color Viewer and the Compositing window closer to the MXO2 for getting better consistency. Of course not for Color grading, but for having better match between the MXO output and the Mac screen. In my testings I think it looks closer with Rec709 both on Color and AE, but I can't really tell.

Apple Color, as I mentioned before, it displays in 1.8 on the display. So, maybe you could have setting on your display to switch between 2.2 for Color and 1.8 for FCP (because FCP switches by itself to 2.2, so you want to be based with 1.8), but not sure if that is accurate. I tried to do the with Eizo display and using its gamma switch but not that accurate. So I disregard the display consistency. It would be good to have something like Blackmagicdesign UltraScope running, so you know you are looking at the right picture and you can see if before rendered and rendered image display the same measurements.

I'll look into more about the AE environment.

Kaku
 
For AE with MXO2 output, unless you change something, it seems to output at 2.22 gamma. Then render in AE as TIFF, the gamma will be 1.8. So when you place that to FCP timeline, unless you have the preference set to bring in as 2.22 (usually set to source gamma) then it will show the material at 1.8 gamma. You can change this by right-click and choose clip information>format and change the gamma from "source" to 2.22. That made the TIFF material display through MXO2 at 2.22 correctly.

Now, I tried the same testing with QuickTime rendering from AE. Be warned that MXO2 with AE only works in 8-bit display mode. You can have 10-bit timeline but MXO2 will only be able to display 10-bit in AE.

I placed the gamma test pattern (dpx created at gamma 2.22) and placed it to the AE timeline, render as 10-bit 4:2:2.
Next placed it to FCP timeline with 10-bit 422 compression setting, the gamma remained 2.22.
 
Thanks Kaku for your help. I really appreciate it.

So far I follow. But my last mystery is the way you transform Gamma 1.8 into 2.2 in Color. Now I understand that Color reads R3d or Tiff secuences as 1.8 Gamma.

But if I place an exact clip in color. One as an r3d and one as a straight Render as a quicktime HQ the only difference in the viewer is the gamma. Color reads the first as 1.8 therefore it looks brighter and have a different contrast ratio to the quicktime.

So I guess the goal is to apply some adjustments to the r3d to not only make it look like the Quicktime HQ, but also that when apply curves and contrast or other adjustments, because they both have the same gamma, a small increment in both clips will create the same results.

If I apply 1.226 in the primary out, the clip gets brighter, and then if I start messing around with curves and gamma I can get the r3d file to a close histogram. But then once I have the similar histogram in both clips, if I go to my secondary and try to make the same change in both clips, the results are different. therefore I assume that both clips are still with different gamma curve.

Confusing.

I will try to make a DVD and see if taking a r3d file in Color (forget about the gamma issue) correct it the way I like it in the MXO2 output, then make a quicktime and then create a DVD. I'll see if the results are consistent with the output of the MXO2 or if it gets darker.

Thanks,

Ivan C.
 
Now I had to start over because I got mixed up with the value you type in for Multibridge Pro's LUT and the master gamma.

I erased the other post because don't want to confuse more people. Give me a minute to sort it out and repost.
 
Here the correct way.

MXO2 with Color, if you are grading R3D, apply 0.810810 to the master gamma while you grade, then upon rendering to DPX, take this away. If you are rendering to YUV QT then burn that master gamma in, so keep the 0.810810 value then render.

Sorry about the mistake.
 
And for Multibridge Pro here the way,

Go to the Decklink control panel, output option, then adjust the 1D LUT's gamma to 1.222222 (this is why I got mixed up, master gamma in Color and decklink's LUT gamma works opposite way). So the Multibridge Pro's output is applied with the LUT, so you don't have to adjust the master gamma. Upon rendering to DPX, Color will apply the gamma shift but you were looking at that change with the LUT you apply.
 
Well, I have CS4 and that's another story. Neat image giving problems, Mocha as well and I guess a lot of Ram problems.

Same here, even with the recent version. Very unstable in 4K.
 
Back
Top