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

RAW workflow - a discussion

Back on topic. Here is a respnse to a question in another thread I guess I should post here too, as I guess not everyone are interested in discussing the images I do... :-)

Sensors see light as linear. The response is (matrixed out to be) linear.

Essentially, a sensor is a photon weight. And the data is mapped "linearily" basically meaning that everytime you add a stop of light, that stop is mapped to the "next" bit, which again has twice the theoretical precission as the previos. Kinda different to our eyes who have "a lot" of precission in the shadows, and "not so high" precission in the highlights.

The RAW data, is basically just that, an untreated "sample" of what levels the sensor weighed, and then wavelet compressed in the RED case

Next step is the Matrix, which is a standardised transorm of the data to adjust for nonlinear response in the sensor in the three channels at different intensitylevels in the exposurerange. AFIK this happens on a per channel level. We cannot turn off the Matrix, so we don't really ever have access to the "raw-linear" data. Early on that was an option, but why would we have access to that, other than if we would like to create our own matrix or would like to reverse engineer Graemes magic soup? But you could say that sensor, filtering, compression AD bit-depth and matrix are the differensating and defining elements in a cameras imagecarracteristics. Because it is from there the rgb image-treatment starts.

As far as I can see, the matrix is not "baked" in the raw data from RED, and is worked on behind the scene all the time. But we haven't had any info from RED on that part of the signalchain since the early days. It is visible, though when there are updates in the color sciences. The updates depend heavily on the mateix linearising the images to a "standard" linearlight container.

So. Here we essential have a linear-light-response untreated image that basically looks very "dark" to our eyes, when a LUT is not applied and it is displayed on let's say a rec709 monitor.

Middle grey, which is slightly important to us, actually falls into an area that looks allmost black, which is quite informative as to how and when noise is generated in images. While the highlights (where our eyes precission is not as good) have tons of precissionlevels available, and thus contain less noise.

After this, some kind of LUT is applied, which basically is a RGB transform into a color/luma space compatible with a screening device and our eyes. And different parts of that process is done with different tools.

Which means that tint is adjusted mostly through adjusting saturation values and thus does not affect the noise in the image unless you go to extremes, while white-balance is done through lifting and clamping the red and blue channel, ballancing them around the green. And ISO/exposure changes where the mid-point hits the scale. These transforms can be done in different ways and that is indeed what differensiate different color tools and cameras even more (when the second transform is done in cam) how they implement the different transforms of the linear rgb image and downsample it into something "viewable" (to be a bit simplistic.)

Point is that all the transforms from the original linearlight rgb image, is actually lossy/noise introducing/and destructive, in a "we want it all" kind of mindset.(yup. I know this is not neccesarilly true for "all" transforms, but this is a lineout to get the general picture...) And the only "true" rgb "standard" we have is actually the post-matrix pre-transformed linear light image that any digital camera creates. That is why exr's in and by themselves are containers for linearlight images (yup, i know you can throw "anything" in that container, just trying to be practical here) and the ACES standardisation move, is based on linearlight signals and standard transforms for "any" camera.

Linear is basically the "rawest" signal we will ever touch from a digital camera.
Most manufacturers bake in some of their own soup besides the matrix in that linearlight image too, where iso and whiteballance are the two most common "baked" elements, which I find kinda understandable, because there is little that differensiate a signal as much as those two elements. That is what gives signature, so you can see it "is a Nikon" or a "Canon" or a "Leica" or a "RED" image.

So having some kind of understanding of how these processes affect the images in different systems, is kinda essential for anyone who have to deal with signalchains and workflows.

Anyhow, back to your question.
Yes. It is a setting in RCX, a "gamma option" which basically can give you the unaltered (but matrixed) RGB RAW data directly from the cam, stored in a 16 bit container, so you don't have to worry about downsampling issues.

As far as I have understood on Michael Cionis and others here and in real life, this is the preferef way to start an image chain, if you have the infrastructure and knowledge to treat it well.

But when we say we want to work "RAW", and want "all the data", practically what we are talking about, is this linearlight untransformed 12-bit in a 16-bit container linearlight rgb image.


Now...
I often don't bother... Hahahahaha
I use this knowledge a lot when working on large scale film/tv projects or have ro analyze and solve image-issues for others. Or when prepping with DP's or setting up solutions for grading or VFX for others.
but for me, privately, it is mostly totally overkill to work that way and also not neccesary. I don't have to go "deep" in imagechains to work on my framing and exposure. But your dng question, made me do some tests as to how much noise I could get rid of in heavily underexposed images by starting off with the linearlight signal and not with the gamma-corrected one.

And I was surprised to find the noise so much smoother when corrected from linearlight, than with the RED gammas. Didn't expect that, really, but goes to prove that the signalchains in RCX is constantly worked on, because I have seen different results when doing similar tests earlier on older builds of RCX.

And that is all good.
Lack of noise is not the only charracteristic in a good image. Textures are important, too. And textures are essentially noise. That makes the image come alive.

But that was the long answer to what I was refering to with the last reply...

Cheers

G
 
Came to think of it...

That was basically the essence of my "Linearlight for dummies" article.

The rest is a couple of months work on documenting the claims I come with, finding differences and similarities in how the signal in different cameras and applications, pointing at the practical use of this by showing how you can look at an image and recognize "symptoms" which would go back to mistreatment of the linearlight signal and suggesting ways to solve that.

Hahahaha

But maybe it is no need foær all that!

I am kinda tempted/not tempted to dive a final couple of months into pure geekery.
Love the more practical application of image knowledge and to try to learn better and controll better the other sides of image creation besides the purely technical ones...

Hm...
 
Yup, and a chapter on how "all digital cameras" basically look very similar and have the same basic challenges, and thus, even on a cam that shoots baked, the knowledge of how linearlight is the base of the image, can help you solve exposure issues and artefacts on set, when working in "destructive" settings. Because wven "destructive" cameras can look great in the right hands.

This is not meant as all photographers or post people need to be engineers to shoot/post. Rather the oposite. Rhe toolset only comes in handy when there are issues you cannot seem to solve "out of the box".
 
But I think something like that, could be a good tool for people testing cameras and systems, to have a clue as to what to look for if there is something in particular they like or dislike about one image over the other.

Optically, a lot can be adjusted for, but I see often that DP's do the exact oposite of what the should do to get the effect they want. The blown highlights in Skyfall at iso 400, because of the "nope, you don"t actually change the sensor when you change iso" issue.

That is when I think some basic knowledge of how digital cameras and workflows actually work, could be usefull in prep and execution. A knowledge at least on level with the former knowledge of different stocks...


Rant over...
 
Ok... Opened that gate...


All cameras are alike... Hahahahaha

Or: after that matrixed linearlight image, everyone have the three basic challenges signalwise..

Iso/where you put middle grey in the exposure latitude ofeered
Whitebalance
And the fact that you cannot swap the sensor when you need to.


These three simplistic challenges, constantly seem to create a lot of confusion...
And they are interpreted in slightly andndramatically different ways by different manufacturers of cameras and software.

Yet we turn those two buttons like they physically change the sensor, and people are confused by the results they see.

But if you wrap your head around how sensors see light, and that data is stored and transformed, it is kinda obvious and predictable what kind of artefacts we will see given a particular transform or order of transforms applied. What attnuates distortion and what lowers distorrtion. And what I find, is the technically "best" result comes when those transformsnare handles by applications that are focused on solving these issues. And THAT - if anything - is rhe beauty of a "raw" image, that those "out of house" solutions really can be allowed to shine.

Ok.

Don't want to drag myself to deep into this thing eight now.
I am setoxing myself for feeky thoughts!

Hahahahaha

And must think a bit before I move further on the subject, if I indeed decide to do so.

I will also need a referencegroup (don't mind tham being anonymus and not supporting my conclusions, but has to be a couple of guys I trust) to discuss my examples with...


Ah...

And a commisioner wwouldn't harm either. Seriously think it is 2-3 months of work, if it is to have some real validity...


Ouch

Haahahahahahahaha
 
There is also the related issue of bit depth and where it matters more and where it matters less and why, which is a lot of mumbojumbo, and also about theAD chain... Should probably be a part of the same article.

(Says the guy that predicts that we'll need 24-bit float ad's and post ro be really happy with our digital images eeplacing rhe analogue options...)

After that, it willonly be signalchains...
 
I am very confused by this.... Can one transfer licences? If so surely brand equity is going to take a kicking?
Do you mean like Resolve brand?:001_wub:
I have no further information beside what I had already stated. I suggest you contact Mistica directly.
 
There are places for linearlight but also quite a few for log.

It is still quite smart to have some understanding of both...
 

Hmmm ... he makes it seem that RAW Linear is a bigger file then log files. A bit of a mix of apples and oranges ... my view is:

Log/Lossy Compression ... such as DNxHD/cineon/prores gives me around .6 megabytes per frame (1080p)
Log Uncompressed ... such as dpx gives me around 8 megabytes per frame (2k)
linear compressed ... such as openexr, gives me around 6 megabytes per frame (2k)
Raw RED ... gives me around 6meg per frame (normally i go full 5k at 3:1, going with higher lossy compression is a lot less)

So i don't think there is that big a difference between file size on linear vs log, and linear/log vs RAW. The big file size difference is when you go to lossy compression(which wasn't the takeaway i got from reading this).

BTW ... does anyone know if in REDCINE-X the openexr output label "ZIPS" is a 1 scan line or a 16 scan line compression?

[ in nuke it's a bit faster to go with a 1 line scanline ... so i try to use ZIP-1 instead of ZIP-16, also don't use the "ZIP" if your outputting from redcinex to openexr for nuke comping ... use the Openexr ZIPS option]
 
There's more to RAW than just DR though - that white balance and ISO are not burned it, neither is colour space too.

Graeme
 
There's more to RAW than just DR though - that white balance and ISO are not burned it, neither is colour space too.

Graeme

Definitely agreed!


I still think Art is good at making things comprehensible. Thus I said it was one good background article.

White balancing is also one of the main reasons we need some headroom in the top when shooting off native WB, to avoid compressed channels. That would be true with any camera I have tested. And the artifacts created by not having enough headroom are only more or less bad, but never good.

But I still think Arts article is a good reference for parts of this.

Maybe I am off... :)
 
Knowing Art pretty well, I can say that he understands the subject completely. Having said that, I also think he wrote this article with the purpose of explaining the differences between linear light and log in a way that the reader would understand the validity of using log encoding to retain deeper bit fidelity when processing images in a "typical" configuration. He didn't mention that Raw files only contain 1/3 the amount of information as an equivalent RGB image because they are a reflection of a Bayer sensor (thus one major reason they're smaller), and he also didn't mention that the primary reason for avoiding Raw in later post processes is largely processing overhead associated with both decompression and debayering. Those things require processing cycles regardless of how many Red Rocket cards you might have, and any computer only has so much horsepower, so performing those tasks at the same time as color grading, scaling, and other things sometimes limits what you can do in real time. That is a hindrance to artists who are used to things being very fluid. I believe what he was trying to point out is that there's no real reason to decode to linear light to retain the information in the Raw files. Transcoding to a log curve retains that information in a much more compact way.
 
My workflow is to keep it RAW for as long as possible. One aspect of shooting 5K is that reframing and stabilizing is possible without a lot of degradation of resolution quality. Whenever I grade Alexa material I cannat reframe at all because it's limited to 1920x1080 and when a debate together with the cinematographer comes up about Alexa versus Red I always point to his poorest composed shot and say, well, you shot that on Alexa so we're screwed on that, if you'd shot it on Epic we could tweak it to perfection and even add a little camera motion in there.

The only thing I'm not really very well into is RAW workflow with a lot of VFX. If say there's a lot of compositing in an edit, should I grade and reframe first and then export to the final resolution before VFX or should I hand over the RAW files to the VFX-artists, let them do their magic and then I go into grading? If so, then I'm stuck with some kind of log and I cannot grade those in RAW anymore.
The feature film I edited we went into DaVinci resolve with the R3D files, grading RAW (we were the first in the world to do this with resolve :) ) and then handed over the graded footage to the VFX artists. Is this common?
 
Another feature of RAW is that the debayer is not baked in as well.
As advances are made, your old footage can be 'upgraded' just like your camera is with firmware updates.

There's more to RAW than just DR though - that white balance and ISO are not burned it, neither is colour space too.

Graeme
 
Another feature of RAW is that the debayer is not baked in as well.
As advances are made, your old footage can be 'upgraded' just like your camera is with firmware updates.

Yes. I agree... But only to some degree.

I work both in "arty" settings where one cherish ones footage and can think of (as money/time isn't really a reason to do what one do) re-conforming to "new color sciences" or 4k or whatever

OTOH I have been working a lot with high throughput situations, too. In hours I guess TV-Drama wins for me, but also commercials.

And the decissions one make are final.
No way 12 hours of TV is re-mastered for a replay from the RAW files. Not here, at least.
And commercials.
Most are best forgotten when they're off the air. Remaster to?

So... there are different realities involved.
I personally enjoy that REDs system let me play along with (as much as "play with" and "play around with") both those ways of thinking within one system. But realistically spoken, if Epic had come out with a prores 444 1080 module that was capable of recording log off the shelf, THAT would probably have made up for more than... let's just say "a lot" would've be recorded that way. And I can totally follow that.

Not every image has "eternal value". and many are better forgotten... Even in 5k+.

We're in a production/consumption "industry".
Which sometimes can be full of art, but mostly is dependant on formulas and craft.
I am not saying I despise craft or high throughput, but those parameters doesn't allways play along well with research and development,
Sometimes they do though...

Ouch

Sorry for taking my own thread OT

But even though I really dig the linear signal we get to play with on the RED, more and more by the day, I think that is not a reason for Art NOT to simplify things so that people can get a grasp and a place to start.

Art digs the Alexa, no surprises there. And he's open about it and don't come around here to bash the RED, Fair, too.

In the end, I really dig that there are many good tools out there finally, and more to come. From RED and others.

So to put this back on track

... and they are all based on sensors with (close to) linear lightresponse (at least kinda after they are matrixed)

The cool thing that makes them different in a good way, are the different choices and approaches the ingeneers have chosen to follow from the DA to the matrix and from there, that's part of what gives even digital cameras a bit of soul and carracter. That, and of course optical filtering, glass and lightchoices.

the cool thing is that these days, you can play around with visual ideas again pretty much (as long as you KNOW your tools) without being limited by your tools.

That has taken a long haul to go 360 from from the initial digital cameras. And RED has definitely been THE driving force in that... I hate revolution... but more of opening up for real a new evolution, that might eventually have the side effect of killing its ancestor.

And that's all based in NOT trying to hide, but let us play with what the cameras really record: A linear light representation of the light we non-linearily see.

Nice to see this discussion move on!
 
Back
Top