Dragon compared to 35mm Vision3 200T

[Hans von Sonntag]

Moreover, I think Bayer pattern re-construction algorithms will always have to compensate to at least some degree for the inherent green bias of 50% of the photo sites having green filters vs 25% red, 25% blue.

The second green filtered photo site which is obviously hardly usable in a RGB triplet must be dropped for colour creation but can be used to enhance resolution in the luminance channel. This is the reason why Red claims that the resolution-loss due to the de-bayer process is not 75% one might think by doing simple maths but is closer to 82%. Still, 4K RAW is not 4k RGB resolution wise. In short, the supernumerous green filtered photo site in the bayer pattern should not have an influence on the colour rendition after the de-bayer process.

As others have noted, a decent colorist with the necessary tools should be able to get a pleasing (even if somewhat inaccurate) look from Dragon, Alexa, etc and that's a part of the creative process regardless of the personality of the capture device.

Cheers - #19

Fully agree.

Hans

 

[Hans von Sonntag]

Maybe its Red Colour 3 (I would have thought in a test like this you would be going with redlogfilm or RGB or something a bit more 'neutral'), ....

RedColour3 is the third iteration of Red's Colour Science with the label "RedColour." RedlogFilm, however, is a log gamma curve and not a colour science. With RGB you probably mean Camera RGB which delivers a neutral, desaturated interpretation of the sensor.

The first thing I checked when I got my hands on my freshly dragonized Epic was the new colour science. With RedColour3 the Dragon sensor is very similar/same to the MX sensor with roughly 2 stops more headroom. With DragonColour enabled in the de-bayer process you get an additional, delicate colour depth. I was never really happy with RedColour but DragonColour is a clear step ahead and surly Alexa realm.

When I find time I will post some pictures.


Hans

 

[Ivan McCullough]

I thought that might be the case. I tend to set the camera (MX) on rc3rg3 because its the newest and probably best interpretation of sensor data. I was not aware it was unavoidable in post to use one of these 'colour sciences'. I suppose we are back to how RAW is RAW....

 

[Hans von Sonntag]

I thought that might be the case. I tend to set the camera (MX) on rc3rg3 because its the newest and probably best interpretation of sensor data. I was not aware it was unavoidable in post to use one of these 'colour sciences'. I suppose we are back to how RAW is RAW....

RedGamma3 is made for dailies. It's a gamma curve that matches Rec709 displays quite well, leaving a bit headroom for shadows and highlights. It's similar to the Alexa Rec709 LUT that people use to make editors and clients happy, prior to grading. But it is surely not the best gamma curve when the goal is to squeeze out the most juice.

RedLogFilm is the curve that maps the 16Bit RAW data best to 10Bit RGB. In the opposite to RedGamma3 it does not favour or amplify certain areas, it is neutral and hence looks dull and flat but is the only usable base for further grading. It's very similar to that what a film neg. looks like.

If you want to compare film to digital give the digital a fair start and use it log encoded for further evaluation/grading.

Hans

 

[Phil Holland]

If you're curious for the vast majority of my work now that the new color science is officially released I'm running:

- In camera (or streaming out for broadcast): DRAGONcolor/REDgamma4
- In post for color grading: DRAGONcolor/REDlogFilm with a curve that is essentially REDgamma4 with a slight variation

That's a nice starting place for me for color work in regards to the REDlogFilm workflow.

The color is really, really good now with the latest sensor calibration and new OLPF. Both of those things make a pretty big difference that's very noticeable not just in color, IR containment in shadows, and internal port IR reflectivity but also in tonal placement and density.

To me it's pretty important for all Dragon owners to get their cameras in and get that new stuff dropped in there. Especially after the fun tests I did.

 

[Ivan McCullough]

RedLogFilm is the curve that maps the 16Bit RAW data best to 10Bit RGB. In the opposite to RedGamma3 it does not favour or amplify certain areas, it is neutral and hence looks dull and flat but is the only usable base for further grading. It's very similar to that what a film neg. looks like.

If you want to compare film to digital give the digital a fair start and use it log encoded for further evaluation/grading.

Hans

Sure, I would not have clients looking at Redlogfilm. I know that is what the posthouse I use mostly ingest with.

What I mean is is there a 'RAW' colour science, ie. not one of the REDCOLOR's which are obviously an interpretation of sesnor data.

ie, is there a less biased colour than REDCOLOR 1/2/3... or is it WYSIWYG essentially colourwise.

 

[Gavin Greenwalt]

RedLogFilm is the curve that maps the 16Bit RAW data best to 10Bit RGB.

Just a nitpick: Most people record Redlogfilm to 10bit DPXes but that doesn't mean RLF is 10 bit. The Linear (native RAW) -> RLF curve is a mathematical function so its bit depth is equal to the input which supposedly is around 16bits from REDCode. So if you apply a Cineon (RLF) gamma space to a 16bit linear RAW image you still have 16 linear bits worth of information. The RLF curve doesn't discard any bit depth. If however you round tripped from 16bit RAW -> 10bit DPX and back -> 16bit RAW obviously you would discard some color resolution.

 

[jake blackstone]

Just a nitpick: Most people record Redlogfilm to 10bit DPXes but that doesn't mean RLF is 10 bit. The Linear (native RAW) -> RLF curve is a mathematical function so its bit depth is equal to the input which supposedly is around 16bits from REDCode. So if you apply a Cineon (RLF) gamma space to a 16bit linear RAW image you still have 16 linear bits worth of information. The RLF curve doesn't discard any bit depth. If however you round tripped from 16bit RAW -> 10bit DPX and back -> 16bit RAW obviously you would discard some color resolution.

Most, but not all. No one stops you from using 16 bit LOG DPX or in case of working with ACES, then it is half float LIN EXR. Either way, there is a zero loss coming and going.

 

[Hans von Sonntag]

What I mean is is there a 'RAW' colour science, ie. not one of the REDCOLOR's which are obviously an interpretation of sesnor data.

ie, is there a less biased colour than REDCOLOR 1/2/3... or is it WYSIWYG essentially colourwise.

Hi Ivan,

In RedCineX only Red's iterations of RedColour is available. In other software packages such as Resolve or Smoke you will find Red's SDK implemented. In the SDK there are also the legacy colour sciences such as RedSpace (this were the early RedOne times) or CameraRGB, AdobeRGB, Rec709, etc... Useful in this range is RedSpace and CameraRGB, everything else is ugly. Camera RGB might be the "RAW" interpretation that you are looking for.

There is no such thing in the de-bayer process as a 1:1 RAW to RGB interpretation, it needs always some tweaking. Prior to Build 16 Iridas developed a de-bayer algorithm for R3Ds that worked on the GPU and was much, much faster in de-coding than the CPU-heavy Red encoder. I remember well how this experimental de-bayer algorithm looked. It was colour-wise nice, close/same as CameraRGB but showed clear aliasing on diagonal rails.

Hans

 

[jake blackstone]

Prior to Build 16 Iridas developed a de-bayer algorithm for R3Ds that worked on the GPU and was much, much faster in de-coding than the CPU-heavy Red encoder.

And so was GPU debayer developed by Assimilate, MTI and couple of others. And that is why R3D became encrypted to prevent GPU debayer at that time.

 

[Marc Wielage]

Just a nitpick: Most people record Redlogfilm to 10bit DPXes but that doesn't mean RLF is 10 bit.

"Most people" is a moving target. I know of several budget-conscious projects where they pre-conform the R3Ds to ProRes 444 2K in RedLogFilm, just to save time. I haven't seen an issue if the final delivery is 2K or 1080 HD for TV.

 

[Frank Cueto]

Marc, that would work. But we love having access to the R3d parameters in the grading session

 

[Björn Benckert]

"Most people" is a moving target. I know of several budget-conscious projects where they pre-conform the R3Ds to ProRes 444 2K in RedLogFilm, just to save time. I haven't seen an issue if the final delivery is 2K or 1080 HD for TV.

It's a difference between "seeing an issue" and work none destructive. A good colorist does not push the colors until the banding is clearly visible, he hold back and make sure he does not let the imagery tear. And a 16bit r3d redlogfilm dumped into 10 bit proress file you clamp colors and add compression for no reason.... and when the degraded redlogfilm 10 bit file is graded I would say you only got about 8 bits left... and yes that limits what you can do to the image before it breaks and that limits the colorist. The reason for degrading the r3d's before grading is very often blamed on budget. But it's very easy to argue that somebody with skills and know how could not only get around the costs, they can also get a faster workflow on the same given machines by not degrade the r3d's before grading.

So blaming budget is not right as I see it and clamping colors always hurt. But yes if you edit with proxies and you think what you have looks fine or just a small touch or tweak of the colors is all that is needed to make it perfect... then fine, just render out the master, same time and money. But if you actually are taking out the EDL/XML and going to a color suite then bring the source r3d's or make a r3d trim and let the colorist work from that. If he can not work form it... well then, he is not the colorist.

 

[Hrvoje Simic]

It's a difference between "seeing an issue" and work none destructive. A good colorist does not push the colors until the banding is clearly visible, he hold back and make sure he does not let the imagery tear. And a 16bit r3d redlogfilm dumped into 10 bit proress file you clamp colors and add compression for no reason.... and when the degraded redlogfilm 10 bit file is graded I would say you only got about 8 bits left... and yes that limits what you can do to the image before it breaks and that limits the colorist

Although superior, 16 bit r3d does not necessarily mean full 16 bits of actual tonality.

Prores 4444 supports 12 bits. Works fine in many cases and simplifies things when that is preferred.
If that 12 bit Prores comes with first light already done in raw, even better.

 

[Paul Russell]

But if you actually are taking out the EDL/XML and going to a color suite then bring the source r3d's or make a r3d trim and let the colorist work from that.

I'm just a one man band and this is my work flow. Perhaps it's cos I don't like making decisions until the very last minute.

 

[Medavoym]

Hi!

Speaking of 16-bits vs 12-bits vs 10-bits etc...

What is the best workflow when you want to apply a Cineon film emulation 3D LUT on top of the RedLogFilm in DaVinci? Working from R3Ds...
I believe the Cineon LUTs are 10-bit.

I usually apply one on the last node and do all the corrections "under" the LUT. Am I preserving as much information as I can, in this instance?
Again, working straight from R3Ds.

Thanks!

 

[Medavoym]

Anyone?

In the context of this thread... (preserving bits)

 

[Tommaso Alvisi]

RLF is not Cineon btw...

 

[Gavin Greenwalt]

RLF is not Cineon btw...

RLF is precisely Cineon.

 

[Tommaso Alvisi]

Gavin, I thought that RLF became closer to Cineon only in RedColor4...

in RedColor3, RLF had to be adjusted to Cineon with an input 3D lut...