Workflow for VFX

[Peter Lyons Collister ASC]

I am sure this has been covered. But VFX house wants DPX files for comp work what is the correct color space and output for DPX so they have the most info to work with.

In film work we scan film at 4K or 2K and make cineon files. There is a standard colorspace and output that is standard across the industry.

Does a standard exist for transcoding r3d files for DPX.

Peter

 

[Kim Frank]

I would also love to know that.
What colourspace is best? Camera Rgb?
What gamma does retain most information redlog or linear light.
And why use 10 bit DPX instead of 16 bit TIFF?
Timecode and storage?

 

[Deanan]

I am sure this has been covered. But VFX house wants DPX files for comp work what is the correct color space and output for DPX so they have the most info to work with.

In film work we scan film at 4K or 2K and make cineon files. There is a standard colorspace and output that is standard across the industry.

Does a standard exist for transcoding r3d files for DPX.

Peter

REDspace or CameraRGB are good starting points for colorspace.

For gamma space, if you're going to 10bit dpx I'd recommend REDlog as it's the most efficient conversion from 12bit to 10bit and can easily be linearized for vfx pipelines either with a lut or with regular cineon log2lin tools. Second choice would be PDlog985.

 

[Rainer Fritz]

So as we saw in our last three projects we got the best results with redspace/redlog and redspace/PDlog685.
To work in a log pipeline, be sure to test a lot and get a proper LUT. Take the money and time and get a cinespace truelight cube for your CC suite. Dont think the standard LUT for scans of your CC suite will fit exact. With PDlog985 we saw that the overhead in grading, specially at the secondaries is not big and CC was painfull in that case.
At PDlog685 we saw that the blacks modulating very nice, like you know it from scans, but the highlights have not that headroom as in redlog. Vice versa the blacks in redlog are modulating less than in pdlog685 but the highlights have much headroom. The colors and contrasts in pdlog685 are for my opinion a little tighter than in redlog. So it was our choice to do a linear grading. So we made a basegrading for redlog that we applied to get a linear base. The results on the screen we saw, as on 35mm print as on the DCP where amazing. We screened it at munich at the digitale cinematographie as well as some inernal screenings, and all i can say is, if people watching to the 35mm print they were stunning, same thing on DCP.
I worked together with the colorist of antichrist, where he choose the log way through scratch. After you have seen the film you know what RED can do. The first slomo shots in b/w are from phantom, except the shot out of the cave and the wide one with the house and fog, rest is RED. But they had to set up their proper LUT for grading in log. So just be sure dont miss this.
CameraRGB had for us not enough chroma, so because of that we choose redspace as the colorspace.
In high contrast scenes, specially exteriors with hard sun light on the skin, we need to work very fine in secondaries to get our desired look of skin tone, but at the end I can say, it looks amazing at our project "NaPutu"....
one thing we took in advantage as well was the possibility to conform direct RAW into the CC. One thing is you get the full color depth in and you have the full control over the metadata. So in hard highlight scenes we had the possibility to change the ISO for example to get more in control of the highlights and could then grade better.
So for me there are two CC systems which work very nice in that case, thats IRIDAS speedgrade DI and Nucoda. Both have pros and cons. speedgrade is resolution independent and gives you in case of GPU accelaration 2k realtime, nucoda has a great degrainer if you need it.

hope that helps
regards
rainer

 

[Jeff Brue]

For god's sake make sure you use the new red alert for vfx shots. Just took some stuff from an old music video that was a nightmare to key, and had the key pulled in under a minute. For TV vfx really think about rec 709 as most vfx houses that are in the commercial world don't know how to deal with LOG.

 

[Evangelos Achillopoulos]

REDspace or CameraRGB are good starting points for colorspace.

For gamma space, if you're going to 10bit dpx I'd recommend REDlog as it's the most efficient conversion from 12bit to 10bit and can easily be linearized for vfx pipelines either with a lut or with regular cineon log2lin tools. Second choice would be PDlog985.

Deanan, if you read carefully Rainer post you will realize that there is no "ONE SIMPLE WAY" to have a proper Cineon 10 bit Log encoded DPX without loosing something...

I'm not going to elaborate but you can understand that your answer is not adequate.

You, Jim and all the other guys at RED team made a wonderful job, a great camera, and you changed the way the market is working.

It will be a pity, after all this achievements, to do not have that solved...

I thing that RED team has to address this issue one day...

 

[Deanan]

Deanan, if you read carefully Rainer post you will realize that there is no "ONE SIMPLE WAY" to have a proper Cineon 10 bit Log encoded DPX without loosing something...

I'm not going to elaborate but you can understand that your answer is not adequate.

You, Jim and all the other guys at RED team made a wonderful job, a great camera, and you changed the way the market is working.

It will be a pity, after all this achievements, to do not have that solved...

I thing that RED team has to address this issue one day...

Everyone's got a different opinion about what's best for post and there really is no "one simple way". We will continue to add more options and flexibility for log workflows though because we often get requests for different types of outputs for log workflows (and they're all different).

 

[Evangelos Achillopoulos]

Everyone's got a different opinion about what's best for post and there really is no "one simple way". We will continue to add more options and flexibility for log workflows though because we often get requests for different types of outputs for log workflows (and they're all different).

I see that you use the plural "log workflows"... can you elaborate how many "log workflows" do you know?

Because me and most of the forum members that we following the one, and only, Cineon 10bit Log encoding for DPX, we know that there is only one.

If you don't know how Cineon is encoded I can assist you...

When we scan film we measuring negative film densities, status M that is, in RGB... film has a base density that we call "base", this is when the negative is developed, in the unexposed area at the perforation of the negative, we have an area that is the total black (unexposed) the base... above that base RGB values (densities) are recorded to negative... so to scan it we zeroing the scanner to the base density that we presume its the total black.

So on Cineon encoding which is 10bit Log we have the following structure on RGB values (0 to 1023 RGB) that are corresponding to negative densities above base.

From 0cv to 94cv (95) is nothing (in real life that is used after color grading that black can go below film black as a headroom)... the black Code Value (cv) is 95cv or 95Bcv (B=black point)... then every 0.002 negative densities, above base, is one Code Value (cv)... so for red negative density 1.002D the cineon value is 1.002D/0.002D=501cv then 501cv+95Bcv=596cv, for green negative value 0.75D which is the 18% gray value the number is 0.75D/0.002D=375cv then 375cv+95Bcv= 470cv... that's the LAD gray card number for those who understand what I'm saying... these values are going all the way up to 1023cv even though 1023cv is equal to 1.856D which is a very rare in real life applications...

Now how do we match these values to sensor linear data?

With scene brightness is the answer.

Study the following table and you will see what is the relation...

Or in that link for more info...

http://www.acvl.org/digital_intermediates/dicompanion/ch02.html#id591490

In the above table someone can realize that 90% white, is just a white with 90% scene brightness, and that there are whiter (brighter is better) whites than the 90%... that happens to be the other magic number that we commonly see and it called white point 685cv... so thats why the PDlog685 clips everything above 685 white... because, for a weird reason that I can't understand, someone on the RedAlert code (or REDCine code) presumed that above that white is nothing... or that it must compress all the values between 95 and 685...

Also its understood that in order to make the conversion of linear sensor data to Cineon values you have to totally disclose the maximum scene brightness that RED sensor can withstand... If that is not being done, totally aligned with the above method, then there will be problems like Rainer is describing...

The rest its just mathematics... that I thing Graeme is very capable of solving...

I just described a very precise description of what we all want...

This is how you going to create DPX files according to Cineon 10bit Log spec.

That is what all want.-

Next time if you don't know something you can just ask for it...

I will copy that post to a new thread to have a discussion on this subject in case there are objections

 

[Marco Graziaplena]

What I can't understand is why RED doesn't give the correct values for a log-to-lin LUT if coming from redlog...
what's the black, the white point, the gamma etc.?

 

[sergio arguello]

Now look what you started Peter....:badputer:

 

[Peter Karlsson]

For god's sake make sure you use the new red alert for vfx shots. Just took some stuff from an old music video that was a nightmare to key, and had the key pulled in under a minute. For TV vfx really think about rec 709 as most vfx houses that are in the commercial world don't know how to deal with LOG.

Are you talking about B20, when saying "use the new red alert"?