DPX or RAW

[Gunleik Groven]

Is it something in the air today or what?
For the billionth time- you can't grade RAW!!!
Every software does the same thing.
1. It decompresses compressed R3D.
2. It debayers it, i.e turns bayered image into linear RGB image.
3. If needed, it maps Linear Gamma into a Video or Log gamma or it is left as a Linear image, which is used for creating an EXR.
4. It may encode into something like DPX (Nucoda), Uncompressed (Resolve or Baselight), EXR for ACES for all grading software or it's variation, like the new Truelight color Spaces for Baselight.
And only then you can apply the first color node or layer, depending on software used.
All this happens in real time, so you may THINK you're grading RAW, but in reality you're ALWAYS grading transcoded RGB image.
The only time you're "grading" RAW is by adjusting the metadata, like FLUT or Color temperature, Tint etc.
Please stop it with FUD. By properly using full RGB encoded uncompressed files for grading you lose NOTHING for reasons I just explained...

Exactly, Jake.

And if you have to go half-debayer or 1/4 debayer to make your grading-software play well while "in raw", you would probably have a better result doing a conformed transcode into something like RLF prores/DPX. Fun part is that you risk having a lot more technical image integrity with a log full debayer prores, than a 1/4 debayer 10 bit "RAW" grade.

This is one of many reasons I am happy to see prores in Weapon:
R3D's may well be the best image container thinkable, but that is often compromised in the workflow for a multitude of reasons (time-/equipment-/comepetence-limits being the biggies). Actually NOT understanding what kind of signal compromises one do with different signalchains (and there are always some sort of compromise), but blindly believing that having "RAW capable software" in itself solves those, is probably the biggest image compromiser.

If you could have flat RLF (+metadata CDL for monitoring "on-set-grading" debayered and transcoded prior to compression directly out of the camera, working the prores could for many give a better result than what is done quite a bit to the RAW files these days, due to people religiously trying to "stay RAW".

RAW capture is extremely great when you need to correct and tweak things. But when you have it "right", then you do, and then it's more a matter of getting the right data in to post in a good way.

(As a side note, I am also curious about the lowlight noise un R3D's vs prores on Weapon. People who hooked up PIX'es to their scarlet for full-sensor framing, reported lower noise in the prores than in the R3D. That could of course be due to better scaling.

I like the idea of full debayered RGB capture before compression, vs:

RAW -> compression -> decompression -> debayer--> RGB (and possibly -> re-compression).

Judging from the Keying tests Gavin Greenwalt published, the directly recorded prores could be a better place to pull a key, than the R3D source. Whether it is then right to use the prores as an alpha source and the R3D as a compositional building stone, will... depend on who you are, I think)

 

[Gunleik Groven]

I'm not talking about putting a mega-gamma on it, not even the Red Gamma, I mean a slight gamma so that it isn't as compressed as RedLOG film is.

When you lower the levels, you lose precission, simple as that.

You'd probably be better off using RLF (or linear/ACES) + some non-destructive display-lut to get the punch without degrading the signal, than what you suggest.

Also Jake is right: As long as the container is bigger than the source and you don't mis-treat the source, you don't lose anything grading from RGB files.

if you do a "small gamma correction", you do however ditch precission. (which BTW can be the absolute right thing to do sometimes. But that is an esthetic, not a technical observation)

 

[Mark Toia]

Jake is very wise. :iagree: DPX's or even ProRes can work fine provided the transcodes are done properly.

1000% agree... I quite often grade my PRORES exports.

But there lays the challenge for lot of people. Setting perfect white balance and gammas before exporting.
I had a FAMOUS post house (NAME REMOVED) do a huge job for me. Their So called COLOR LAB that did all the transcodes to DPX for the project was absolutely terrible.. The final DPX's were soft and way of white balanced.
To prove a point I did some transcodes in my laptop right in front of them which were pin sharp, perfectly white balanced with miles of detail in the highlights and shadows. 100x better than theirs.
I ended up doing all the transcode for them, as there was no way I was going to let them even think about using the shit they coffed up.

At the end of the day there is nothing wrong with DPX or PRORES for grading if have good files to work from.

Anyways.. This is a common problem, even with the Big boys.

I'd personally grade from the RAW source, Especially if you have no idea about how to perfectly colour balance before transcoding to a colour baked world.

Is it something in the air today or what?
For the billionth time- you can't grade RAW!!!
Every software does the same thing.
1. It decompresses compressed R3D.
2. It debayers it, i.e turns bayered image into linear RGB image.
3. If needed, it maps Linear Gamma into a Video or Log gamma or it is left as a Linear image, which is used for creating an EXR.
4. It may encode into something like DPX (Nucoda), Uncompressed (Resolve or Baselight), EXR for ACES for all grading software or it's variation, like the new Truelight color Spaces for Baselight.
And only then you can apply the first color node or layer, depending on software used.
All this happens in real time, so you may THINK you're grading RAW, but in reality you're ALWAYS grading transcoded RGB image.
The only time you're "grading" RAW is by adjusting the metadata, like FLUT or Color temperature, Tint etc.
Please stop it with FUD. By properly using full RGB encoded uncompressed files for grading you lose NOTHING for reasons I just explained...

Agreed.

But in responce.. your still working from a RAW file, even though its going through a realtime debayer process.
So you can't say your not working RAW when you technically are, but not...

Anyways, I your rant is correct.

 

[Christoffer Glans]

For the billionth time- you can't grade RAW!!!
.

That's not what I said... I said that the first settings, the ones handling R3Ds through the SDK from Red, the RAW-settings is managing the R3D files. Everything you do from that on is RGB. So I might have said "first node" but what I meant is earlier in the input before the first node. If it were all just RGB, you wouldn't be able to change ISO, white balance and so on. When grading R3D-files, the input is RAW, while the grade is RGB.

So yes, what you describe as "grading in RAW" is exactly what I meant if you read what I wrote instead of lashing out.

When you lower the levels, you lose precission, simple as that.

You'd probably be better off using RLF (or linear/ACES) + some non-destructive display-lut to get the punch without degrading the signal, than what you suggest.

Also Jake is right: As long as the container is bigger than the source and you don't mis-treat the source, you don't lose anything grading from RGB files.

if you do a "small gamma correction", you do however ditch precission. (which BTW can be the absolute right thing to do sometimes. But that is an esthetic, not a technical observation)

If you code a DPX in log mode from a R3D file you have locked a certain value of DR. Even though it has massive amount of data in it, it's still locked and stretched in RGB when applying gamma or a first "stretch" into a more pleasant contrast.
I don't see how I ditch the precision by applying a little more contrast to the RAW image before rendering out to DPX. If I do that I take the RAW data and pull as much information out as possible into the 10 bit DPX. It uses more of the range locked into it's RGB form.
Then in grading I stretch it out slightly more for the first balancing node. It's the same principle as why low end DSLRs shouldn't shoot in a log mode, because it's destructive. Even though DPX has much more data in it, it would still be "compressed" compared to all the data stored in the RAW file.

Working in ACES format is another beast because it stores the "original data" from the camera, or that's the principle from what I've read about it. It's meant to enable increased DR, bits etc. whenever we have screens in the future that can process it, so the data is as uncompressed as it can be without being RAW, right?

 

[Mark Toia]

That's not what I said... I said that the first settings, the ones handling R3Ds through the SDK from Red, the RAW-settings is managing the R3D files. Everything you do from that on is RGB. So I might have said "first node" but what I meant is earlier in the input before the first node. If it were all just RGB, you wouldn't be able to change ISO, white balance and so on. When grading R3D-files, the input is RAW, while the grade is RGB.

So yes, what you describe as "grading in RAW" is exactly what I meant if you read what I wrote instead of lashing out.



If you code a DPX in log mode from a R3D file you have locked a certain value of DR. Even though it has massive amount of data in it, it's still locked and stretched in RGB when applying gamma or a first "stretch" into a more pleasant contrast.
I don't see how I ditch the precision by applying a little more contrast to the RAW image before rendering out to DPX. If I do that I take the RAW data and pull as much information out as possible into the 10 bit DPX. It uses more of the range locked into it's RGB form.
Then in grading I stretch it out slightly more for the first balancing node. It's the same principle as why low end DSLRs shouldn't shoot in a log mode, because it's destructive. Even though DPX has much more data in it, it would still be "compressed" compared to all the data stored in the RAW file.

Working in ACES format is another beast because it stores the "original data" from the camera, or that's the principle from what I've read about it. It's meant to enable increased DR, bits etc. whenever we have screens in the future that can process it, so the data is as uncompressed as it can be without being RAW, right?

I hear you.
And Don't worry about Jake, He's just trying to out Geek you with techno babble, Your both saying the same things, but differently.

At the end of the day you can grade from the original RAW file and change tints and all sorts of things, even though your technically not... as Jake said, becuase hes correct also.

However... Once you drop into a DPX world, you are then correct.. you now cannot change over all colour temp or tint without major dicking around. You are effectively now stuck in a colour baked packet with less information and less over all colour control.
Fact.

 

[Björn Benckert]

In case of "Gone girl", the conformed movie was delivered to LI for grading in DPX form. Grading from RAW is overrated and often unnecessary, especially where VFX are used...

Not so much that its overrated. But more that you can not really comp in raw or in log. That goes pretty much for all comp software. So even if it´s all done with live nodes the material needs to be log (raw) then one node turning it into linear, then comped and then flopped back to log again after comped and then graded... as VFX or compositing is quite demanding as it is without doing that round trip in each and every input source most compositors prefer to get a lin material or at least graded log material with a log to lin lut and corresponding lin to log reverse lut if it goes back to grading after composting.


Flame got a nice work flow for such roundtrip with their custom color transform nodes that can also be applied as meta data inside a clip but also as seperate nodes. Aftereffects does really handle these things as nice.

shown here: https://www.youtube.com/watch?v=xlPxcOM3hFM&list=TLNDBq-38_cdgxMjA4MjAxNQ

I hear you.
And Don't worry about Jake, He's just trying to out Geek you with techno babble, Your both saying the same things, but differently.

At the end of the day you can grade from the original RAW file and change tints and all sorts of things, even though your technically not... as Jake said, becuase hes correct also.

However... Once you drop into a DPX world, you are then correct.. you now cannot change over all colour temp or tint without major dicking around. You are effectively now stuck in a colour baked packet with less information and less ver all colour control.
Fact.

Agree with mark for aftereffects nuke etc. As those softwares are a bit fiddly to to keep a pre comp / sub render or whatever of the r3d without creating new clips etc. Then if you need the material in a 3D world / 3D tracking software or whatever then DPX it is.

 

[jake blackstone]

+1, also how I explain it to some people is that you loose the r3d no matter what after you do the compositing, so it's impossible to grade to raw post composite. (i.e. no program can "write" a new R3D). Now some people don't want to go through compositing, I say good luck to that. Another thing is almost everything is max 12 bits after it goes through compositing, and is easy 10 bits in log ... so the only reason to keep more then 10 bits log is if the compositors went outside the color gamut (above 1.0 rgb values I view as screw ups where people didn't linearly add with alpha multiplies during compositing).

I btw would like to look over someones shoulder to understand true light color spaces for baselight.

This is the best explanation of the Truelight Color spaces I know.
http://www.filmlight.ltd.uk/resources/video/baselight/FLT-BL-0027-Baselight-13.php
http://www.filmlight.ltd.uk/products/truelight/overview_tl.php

 

[jake blackstone]

And Don't worry about Jake, He's just trying to out Geek you with techno babble, Your both saying the same things, but differently.

At the end of the day you can grade from the original RAW file and change tints and all sorts of things, even though your technically not... as Jake said, becuase hes correct also.

However... Once you drop into a DPX world, you are then correct.. you now cannot change over all colour temp or tint without major dicking around. You are effectively now stuck in a colour baked packet with less information and less over all colour control.
Fact.

First of all, I take offense to a term "techno babble". I guess stating facts on RU now constitutes "geeking out". Fine...
And no, we are not saying the same things in the same wane, as you yourself, AGAIN, misstating one simple fact:
"Once you drop into a DPX world, you are then correct.. you now cannot change over all colour temp or tint without major dicking around. You are effectively now stuck in a colour baked packet with less information and less over all colour control"
This statement, again is incorrect. Changing color temperature is quite trivial, if done correctly, but I don't want to confuse you with fancy terminology, like Bradford formulas and Chromatic Adaptation Matrices. Hey, i'm just a stupid colorist, who doesn't know how to properly transcode R3D to DPX, right?
And no, you are not "stuck in a colour baked packet with less information and less over all colour control". I use Nucoda, Baselight, Resolve, Lustre and they all grade using RGB encoded material, despite what you keep repeating. Grading RAW, any RAW is a fallacy. It doesn't exist, there is no advantage to grading RAW or transcoded material from the color science point of view. Only reframing can benefit using the original RAW size...

 

[Blair S. Paulsen]

(snip) If you code a DPX in log mode from a R3D file you have locked a certain value of DR. Even though it has massive amount of data in it, it's still locked and stretched in RGB when applying gamma or a first "stretch" into a more pleasant contrast.
I don't see how I ditch the precision by applying a little more contrast to the RAW image before rendering out to DPX. If I do that I take the RAW data and pull as much information out as possible into the 10 bit DPX. It uses more of the range locked into it's RGB form. (snip)

Both 10 bit log DPX and 16bit linear light (no gamma) EXR/TIF variants are robust formats for post work when properly utilized. As noted by others, just being in RAW is not a magic bullet.

I'm afraid that adding contrast does indeed reduce precision, but as Mark Toia notes, and Christoffer implies, if done with care it does very little actual damage.

Many people equate staying in RAW with R3Ds as the only road to re-framing, stabilizing, etc but that's a fallacy - nothing is stopping you from making full raster RGB files. Due to storage space issues, one may adapt a strategy that avoids writing out hours of 6K OpenEXR files, but it's a choice.

IMO: it's all about capturing and maintaining as many discrete code values as you can. If your whole show is native RAW camera files, no VFX, you have lots of rational options - but this thread is chiefly about projects that at the very least do digital compositing of elements from other sources.

Assuming a balancing "one-light" RAW "development pass" that neither clips nor crushes you can certainly make 16bit half float OpenEXR RGB media suitable for the heaviest of post processing. The problem is massive demand for high speed storage pools to work in OpenEXR (or TIFF) at 4K or higher resolutions, read $$$$. This leads many to use 10 bit log DPXs, or ProRes, or...

For anyone not familiar with the math behind log encoding, it takes advantage of two key factors:

1) Linear light encoding puts each value in it's absolute corresponding place. Simple and fixed. Unfortunately it is based on a 2,4,8,16,32,64,128,256,512,1024,2048,4096,8192,16386, 32772, 65564, ... scale that respects the volumetric properties of light but results in radically different levels of precision along the scale.

2) Log encoding schemes remap the values (similar to how a LUT works) to more evenly spread the available code values per stop. The Cineon based log curve, used in RLF, ARRI's Log-C and other variants also takes advantage of the specific performance parameters of the human visual system. It actually tosses some code values that are extremely hard to perceive in exchange for devoting more of the data set to code values that humans can keenly discern - skin tones for example.

Every project has it's own "profile" that largely determines best practices. That said, "developing" the RAW data set into a high precision RGB format - with input from the DP - then sending it down the post pipeline, is typically the most reliable method for maintaining creative intent and avoiding problems. For example, the ARRI Alexa didn't just offer ProRes, it offered ProRes with Log-C encoding that maintained sufficient precision for normal color grading, matching, etc. Sure, ProRes is a compressed format that falls apart more easily in an extreme grade, but how often does one need to go so far away from the look they created on set that it would matter?

I'm a RAW development guy all the way, but If the Weapon can write out nice looking ProRes in RLF color space with a non-destructive RMD sidecar file and a rec709 LUT for monitoring/dailies/editorial, then many fast turnaround projects will take that route. It also levels the field a bit in RED vs Alexa decisions...

Cheers - #19

 

[Gunleik Groven]

This statement, again is incorrect. Changing color temperature is quite trivial, if done correctly, but I don't want to confuse you with fancy terminology, like Bradford formulas and Chromatic Adaptation Matrices. Hey, i'm just a stupid colorist, who doesn't know how to properly transcode R3D to DPX, right?
.

Hey Jake... Peace.
Noone here have suggested you don't know how to do the transcode right, this is Christopher here asking a few friendly questions.
Like I and a gazillion others have been doing here. And learning a tremendous lot from guys in the know - like you.

There is really no offense, as I can see it.
Just a willingness to learn.

And I can really get the way of confronting knowledge, like yours, with beliefs one might have, to get perspective on them.
Personally I kinda like that stubbornness, because it can lead to real knowledge instead of just hearsay.

And I for one would love to know about Bradford formulas and chromatic adaption matrices.
Not really getting my head chopped off for being curious, but just from being curious.
(though curiosity infamously kills cats, and thus I could be an endangered species).

I would also love to know how that knowledge is practically applicable in say Resolve.

But this is really nothing to get worked up about.
You know which forum you're on. It's not Color Science Specialists United, or the Academy Tech Committee.

We're mostly just a bunch of shooters trying to make the most of our tools and trying to enhance our skills to do that well.

And I hope you know your input is appreciated.

@ Blair. Thanks!

I tried to say that in a lot more clumsy ways. There is a technical degradation and a practical way to achieve esthetic goals.

Actually we rarely "want it all", we just want a huge sack of data to select from. That is why I tried to emphasise that technically you lose precission when you lower the blacks, but it might still be the right choice esthetically.

But the numbers of a binary chain, is actually a lot more convincing.

Thx guys for all the input, and please let it flow on.

 

[Michael Tiemann]

Some Wikipedia entries are instructive:

1. [In 2004,] Viggiano found that white balancing in the camera's native RGB tended to produce less color inconstancy (i.e., less distortion of the colors) than in monitor RGB for over 4000 hypothetical sets of camera sensitivities.[8] This difference typically amounted to a factor of more than two in favor of camera RGB. This means that it is advantageous to get color balance right at the time an image is captured, rather than edit later on a monitor. If one must color balance later, balancing the raw image data will tend to produce less distortion of chromatic colors than balancing in monitor RGB. [See https://en.wikipedia.org/wiki/Color_balance#Color_balance_and_chromatic_colors]

2. https://en.wikipedia.org/wiki/Color_appearance_model

3. Bradford model: https://en.wikipedia.org/wiki/LMS_color_space#CIECAM97s.2C_LLAB

4. Bradford model replaced/updated by https://en.wikipedia.org/wiki/CIECAM02

 

[Blair S. Paulsen]

Knowing as much as you can about codecs, signal chains, color spaces, bit depth, file formats, human visual performance, etc is part of becoming the best image author you can be. That said, time is finite and job one is just to avoid killing a well crafted image along the post pipeline by doing something stupid.

RED gives us a tremendous RAW data set to work with that provides tons of flexibility, but even at the capture stage knowing a bit about how codecs operate can make a difference. Many scenes can be shot at 8:1 or greater compression ratios with no significant degradation of the image - other scenes need to be shot at 5:1 or less to avoid artifacting and softness. From there to the creation of the master there are lots of choices one can make that will influence the outcome.

Cheers - #19

 

[Gunleik Groven]

Knowing as much as you can about codecs, signal chains, color spaces, bit depth, file formats, human visual performance, etc is part of becoming the best image author you can be. That said, time is finite and job one is just to avoid killing a well crafted image along the post pipeline by doing something stupid.

Amen

 

[fred gasc]

This thread is tremendously interesting for newcommers like me,
Currently on the learning curve.

But it shows again and again (and
Again and again...) the importance of terminology as well
As confusions and-or concepts that
Are understood differently by people who aren't beginners, (wich is quite intriguing) so in the end we end with several interpretations of a same topic when
The reality is one and can not be different
Interpretations of one.

Could we end to an agreement and a definitive resuming of all that has been discussed here that everyone's
Agree as being information?

 

[Mark Toia]

I use Nucoda, Baselight, Resolve, Lustre and they all grade using RGB encoded material, despite what you keep repeating. Grading RAW, any RAW is a fallacy. It doesn't exist, there is no advantage to grading RAW or transcoded material from the color science point of view. Only reframing can benefit using the original RAW size...

Yeah yeah... we all have base light, Resolve lustre at our finger tips and all see the associated issues with baked grading. And not saying grading from R3D's is all perfect either. However, I get a much better image from directly grading from that file instead of a badly transcoded DPX.
Thats also said, A perfectly white balance LOGc or RLF transcoded Tiff, DPX, PRORES or JPG for that matter will do my just fine for grading.. I'm just cutting out a process or should I say... Letting that process happen in real time instead of having to transcode.

Anyways, You keep convincing yourself grading a colour baked file is the way to go... I'll stick with my shitty RAW & EXR work flow. ...ooooh thats right. Its not RAW. Sheesh. I forgot ..

Moving on...

Both 10 bit log DPX and 16bit linear light (no gamma) EXR/TIF variants are robust formats for post work when properly utilized. As noted by others, just being in RAW is not a magic bullet.

I'm afraid that adding contrast does indeed reduce precision, but as Mark Toia notes, and Christoffer implies, if done with care it does very little actual damage.

Many people equate staying in RAW with R3Ds as the only road to re-framing, stabilizing, etc but that's a fallacy - nothing is stopping you from making full raster RGB files. Due to storage space issues, one may adapt a strategy that avoids writing out hours of 6K OpenEXR files, but it's a choice.

IMO: it's all about capturing and maintaining as many discrete code values as you can. If your whole show is native RAW camera files, no VFX, you have lots of rational options - but this thread is chiefly about projects that at the very least do digital compositing of elements from other sources.

Assuming a balancing "one-light" RAW "development pass" that neither clips nor crushes you can certainly make 16bit half float OpenEXR RGB media suitable for the heaviest of post processing. The problem is massive demand for high speed storage pools to work in OpenEXR (or TIFF) at 4K or higher resolutions, read $$$$. This leads many to use 10 bit log DPXs, or ProRes, or...

For anyone not familiar with the math behind log encoding, it takes advantage of two key factors:

1) Linear light encoding puts each value in it's absolute corresponding place. Simple and fixed. Unfortunately it is based on a 2,4,8,16,32,64,128,256,512,1024,2048,4096,8192,16386, 32772, 65564, ... scale that respects the volumetric properties of light but results in radically different levels of precision along the scale.

2) Log encoding schemes remap the values (similar to how a LUT works) to more evenly spread the available code values per stop. The Cineon based log curve, used in RLF, ARRI's Log-C and other variants also takes advantage of the specific performance parameters of the human visual system. It actually tosses some code values that are extremely hard to perceive in exchange for devoting more of the data set to code values that humans can keenly discern - skin tones for example.

Every project has it's own "profile" that largely determines best practices. That said, "developing" the RAW data set into a high precision RGB format - with input from the DP - then sending it down the post pipeline, is typically the most reliable method for maintaining creative intent and avoiding problems. For example, the ARRI Alexa didn't just offer ProRes, it offered ProRes with Log-C encoding that maintained sufficient precision for normal color grading, matching, etc. Sure, ProRes is a compressed format that falls apart more easily in an extreme grade, but how often does one need to go so far away from the look they created on set that it would matter?

I'm a RAW development guy all the way, but If the Weapon can write out nice looking ProRes in RLF color space with a non-destructive RMD sidecar file and a rec709 LUT for monitoring/dailies/editorial, then many fast turnaround projects will take that route. It also levels the field a bit in RED vs Alexa decisions...

Cheers - #19

Blair on the other hand is making complete sense.

Maybe its the way he delivers his message.

Knowing as much as you can about codecs, signal chains, color spaces, bit depth, file formats, human visual performance, etc is part of becoming the best image author you can be. That said, time is finite and job one is just to avoid killing a well crafted image along the post pipeline by doing something stupid.

RED gives us a tremendous RAW data set to work with that provides tons of flexibility, but even at the capture stage knowing a bit about how codecs operate can make a difference. Many scenes can be shot at 8:1 or greater compression ratios with no significant degradation of the image - other scenes need to be shot at 5:1 or less to avoid artifacting and softness. From there to the creation of the master there are lots of choices one can make that will influence the outcome.

Cheers - #19

AMEN.

Lets leave it at that
Thanks Blair.

 

[fred gasc]

What I personaly extract
(correct me if I'm wrong)
Of this thread is that: in the moment
Any sort of compression does not occur,
We don't loose any infornations
From recorded raw datas?

What would really
Be constructive is that we could clear
All that once for awhile.

 

[Gunleik Groven]

What I personaly extract
(correct me if I'm wrong)
Of this thread is that: in the moment
Any sort of compression does not occur,
We don't loose any infornations
From recorded raw datas?

What would really
Be constructive is that we could clear
All that once for awhile.

RAW on RED is compressed.
If you go to a 16-bit RGB format (like Mark T suggests with the EXRs, but 16-bit DPX is possible as well), you don't lose data when transcoding.
In fact (as Jake points out over and over) you don't really grade in "RAW" but with a debayered RAW signal.

As to precission and how that relates, Blairs post pretty good.

We don't really disagree as much as some of the remarks here can make it look like.

 

[fred gasc]

Thanks Gunleik.


But then the starting point (the format)
becomes irrelevant when curves are concerned.

I mean, maths are the very same.

If you read a R3D and switch, from the source
settings to RLF, or, if you read a
linear version and add a lin-to-log cineon node,
the images are exactly the very same.

So no matter if your log image as been generated
by RCX, NUKE, and no matter the format, (EXR, TIFF, Prores),
no matter the softwares,
your grading starting point will be the very same in the sense
that maths are the very same.


So the only difference really resides in 10bit or 16bit.

 

[fred gasc]

In other words, in the moment we choose a "non-destructive"
format, we're not anymore in R3D in the sense that we can not
anymore affects metadatas, but nothing in the image itself
is lost in the pipeline. Or yes?


So that leads to a question: if it's all the same in the end,
why transcode fo grading? (assuming no comp is required)
Why not simply grading from the R3D?


Isn't that the same if I grade directly from a R3D switched to RLF from
the source settings than if I grade a transcoded RLF version?
So why should I loose time in transcoding a R3D?

 

[fred gasc]

Copy-paste here a Graeme's post from the Aces thread:

"...the math is exactly the same no matter if it's done to EXR on via the SDK in an app. Either way the image should be identical.
when I refer to precision of the EXR I mean the half-float precision is necessary because of the wide colour space and wide dynamic range encoding.
If you attempt to squeeze that same gamut and DR into a 10bit DPX you'll begin to loose precision".