ACES...

[Marc Wielage]

...work with HDTV standard - eg no log space, limited dynamic range (what people do - which is really bad because you clip stuff)

Note that there's "HDTV" and there's "modified HDTV." I've done plenty of shows (as has Mike Most) where we actually had a sort of "pseudo-log" 10-bit image captured in 1080 HD, which was then brought down and color-corrected for Rec709 colorspace, essentially a custom LUT. The Martin Scorcese concert documentary Shine a Light was done this way to HDCam-SR, I think over 300 hours of footage. It made it all the way to film out, DCPs, even Imax, and no one cared or noticed.

So it can be done. I do agree with your other points, that R3D isn't always the best solution, especially for a film with massive changes, or a TV series on a very tight schedule.

I'd like to know how Light Iron is handling Criminal Minds. That's a tough show that pushes the envelope in terms of exposure, plus they shoot a lot of footage. I think R3D can work under certain conditions, but again -- comparing it to old school film log -- there was zero industry standards in terms of what a one-light film scan was. ILM, Technicolor, eFilm, Company 3, Imageworks, Digital Domain... nobody used the same standard. The same piece of film sent to all six places will be different. The same Red footage debayered by different people using different software will look different.

As long as the essential pieces of the image are there, any good colorist can still make reasonable pictures, even great pictures. It's for this reason that the most important advice I always give to my clients is, "test the workflow first" just to make sure the system you have in place will function. I think there's about ten different log settings that will pretty much work, but my preference is for something that's essentially balanced and not biased towards one color channel, and nothing's blown-out.

ACES is a great system for the future, and I think it goes a long way towards solving the problems posed by the original CDL (color decision list) from almost 10 years ago. It's not quite there yet. The other problem is the number of different formats thrown into productions; now that we have the Canon C300 to deal with (followed soon by the C500), there will be undoubtedly be new wrinkles of log-format files -- some indiscriminatly mixed with Red files. It's not unusual to deal with Rec709 footage, log footage, crushed footage, and blown-out footage, all within the same project, sometimes even within the same scene. From where I sit, the problem is getting worse, not better.

 

[Bruce Allen]

It is all about how you get to EXR... we understand that VFX needs this. It is just about how you get there. You can't screw it up by putting a predetermined look on it or inducing artifacts in the process. Currently ACES does both.

Jim

OK - but I seriously think RED should go a little easy on the "Stay R3D until the end, don't convert to a film pipeline" rhetoric...

Because you're setting up a false contrast in many folks minds:
EG it's "stay in R3D (good) vs convert to RGB and clip (bad)"
when it should be "stay in R3D (good) vs convert to RGB properly (good) vs convert to RGB and clip (bad)"

Many indie REDusers say "oh great, Jim says I must stay R3D and not convert... don't do Log or anything like that".

And then they hit VFX and go "WTF do we do now?"

They haven't researched proper RGB intermediates (they believed the "stay in R3D, edit the RAW 4K in Adobe" propaganda).... then they hit this huge workflow mess right in the middle of the proejct.

The VFX guy gets handed either a clipped, Rec-709 image... or an R3D, with either no idea how it should be developed... or they give him settings and those settings suck because they clip.

This is one reason RED has a bad post reputation.

Contrast this with Alexa, where Arri basically encourages people to use LogC, in a clear manner, with defined look up tables, etc.

If RED doesn't want people to use ACES, they should encourage the use of RedLogFilm with 709 or P3 primaries... not staying in R3D. My 2c. The documentation of best practices for working with RED footage in a RGB intermediate format is kinda inadequate and "stay in R3D" is just confusing things.

My 2c. Personally I don't have this problem (because I ignore exhortations to stay R3D and instead figured out how to do RGB properly...) but I see it happening all the time.

Bruce Allen
www.boacinema.com

 

[Jannard]

Bruce... sorry to have an opposing view. Why don't we see what others are doing? You just might be surprised.

I'm meeting with Peter and his group next week. I'll report exactly what they are doing on The Hobbit. That probably is telling...

LightIron has the most experience with RED footage. Maybe Michael can weigh in?

Jim

OK - but I seriously think RED should go a little easy on the "Stay R3D until the end, don't convert to a film pipeline" rhetoric...

Because you're setting up a false contrast in many folks minds:
EG it's "stay in R3D (good) vs convert to RGB and clip (bad)"
when it should be "stay in R3D (good) vs convert to RGB properly (good) vs convert to RGB and clip (bad)"

Many indie REDusers say "oh great, Jim says I must stay R3D and not convert... don't do Log or anything like that".

And then they hit VFX and go "WTF do we do now?"

They haven't researched proper RGB intermediates (they believed the "stay in R3D, edit the RAW 4K in Adobe" propaganda).... then they hit this huge workflow mess right in the middle of the proejct.

The VFX guy gets handed either a clipped, Rec-709 image... or an R3D, with either no idea how it should be developed... or they give him settings and those settings suck because they clip.

This is one reason RED has a bad post reputation.

Contrast this with Alexa, where Arri basically encourages people to use LogC, in a clear manner, with defined look up tables, etc.

If RED doesn't want people to use ACES, they should encourage the use of RedLogFilm with 709 or P3 primaries... not staying in R3D. My 2c. The documentation of best practices for working with RED footage in a RGB intermediate format is kinda inadequate and "stay in R3D" is just confusing things.

My 2c. Personally I don't have this problem (because I ignore exhortations to stay R3D and instead figured out how to do RGB properly...) but I see it happening all the time.

Bruce Allen
www.boacinema.com

 

[Bruce Allen]

Bruce... sorry to have an opposing view. Why don't we see what others are doing? You just might be surprised.

I'm meeting with Peter and his group next week. I'll report exactly what they are doing on The Hobbit. That probably is telling...

LightIron has the most experience with RED footage. Maybe Michael can weigh in?

Jim

Not opposing... I love RAW! I just think that RED should focus more on how to make a good RGB file early on that people can grade from... and less on "screw RGB, stay RAW"

Because average RED owners don't learn how to make a good RGB intermediate file (which is a different skill from making a good contrasty RGB output).

I would love to hear from LightIron and of course Peter Jackson. I had the pleasure of meeting Ian Vertovec when I did VFX on TimeScapes - awesome guy!

I imagine that Weta and everyone else are all going to DPX or EXR/SXR (stereo EXR) frames relatively early - and ignoring the "stay in R3D" mantra.

http://www.lightiron.com/news/creative-cow-4k-di-girl-dragon-tattoo
"Because of the amount of visual effects, Red RAW files cannot be used in the DI."

Anyway, much respect, Jim! Thanks for the open and awesome discussion as always.

Bruce Allen
www.boacinema.com

 

[Martin Stevens]

Great thread.....Thanks to all.

 

[Nikhil Kamkolkar]

Amazing thread indeed. Sorry to weigh in with nothing more than this, but just wanted to share that this is awesome sharing of knowledge. Acquisition is indeed key, but helping setup a best practice workflow that people can then build variations on is also another important key. Glad this is now a stated focus at RED.

 

[Gunleik Groven]

Well... Point is kinda mute, as the noble Gentlemen Most and Cioni has pointed out a number of times.

As long as you non-destructively bring in all data either out of the Rocket/SDK OR through a transcode to 16 bit EXR/DPX, the signal you grade on is the same (Or... it's not "identical" from either the rocket or the SDK, but that's besides the point in this context...). What comes out of the SDK/Rocket is an RGB signal...

What is not too often focused, which I think Bruce is talking about, is that you can easilly mess up the signal (as to "technical pristine" or not - not aesthatically, which a totally different discussion) with the metadatasettings, and then it doesn't in any way help you that you haven't transcoded and stay "RAW".


Just for the heck of it, try this:
Set metasettings in resolve for the same "fully exposed from high to low" image (or any other "RAW" grader), to Redspace/Redspace at 1000 and 250 ISO, and check what you can pull out of the highs and lows.

Compare that to RedLogFilm @ 500

Play with the WB on that same clip with all those settings.

Compare the results.

Nice example of crap signal in = crap signal out "RAW" or not

Main point being that since the early Scratch and color implementations of RAW grading - that weren't really all that good - we actually grade on a converted RGB signal, which noise and signalwise is how it should be.

In the early RAW graders, we had to do "weird shit" to lock us into RGB, so we didn't mess up the developed signal and add unwanted noise in the grade.

By now, this is more a matter of preference and RAID/SAN pipelines, computing powers available and optimisation, rather than a religious either/or debate.

And I am very happy that that is the case!

But you don't neccesarily gain anything but diskspace and slow computerperformance by staying RAW.

If you want this documented, I may be willing to comply...


And this is - BTW - tool independant...

Hm...

This discussion - interesting as it is - is kinda derailing the ACES discussion, which is even more interesting IMHO...

G

 

[Jose Lomeña]

I don't know how big production do this, but for low cost we prefer raw until final grading. 5K tiff is too big!!, and resize is something that i don't want to loose. You can't sacrifice all for some fx shots.

 

[Gunleik Groven]

I don't know how big production do this, but for low cost we prefer raw until final grading. 5K tiff is too big!!, and resize is something that i don't want to loose. You can't sacrifice all for some fx shots.

and we don't...

 

[Jose Lomeña]

and we don't...

In my opinion, If you convert to tiff 16bit, you loose:
1. Space
2. Raid or network speed
3. Color space
4. White balance too early
5. HDR not separate

I do this for vfx shots only. The rest RAW.

 

[Gunleik Groven]

In my opinion, If you convert to tiff 16bit, you loose:
1. Space
2. Raid or network speed
3. Color space
4. White balance too early
5. HDR not separate

I do this for vfx shots only. The rest RAW.

Simply put: That is a marketing preconception.
Run some tests.

Of course you can fit all data (if you want and do it right) drom a 12-bit lin image into a 16 bit container. No discussion. AND because of the tools you have or have not available, it can be easier, better and more predictable to correct that way. Or not.

There is no "one" answer to this.

But you definitely throw off more data and create more noise with a simple wb to tungsten, than by taking the linear signal to 16 bit exr uncompressed... NOT that that is allways wrong.

Wanna bet?

 

[Gunleik Groven]

BTW. I don't say it is allways wrong to ditch data or introduce new noise. For a lot of applications that is littelarily unnoticable and a good way to save heaps of time and space.
And if that's the way it looks good, it's the right thing to do!

Simplicity often is the best way to achieve the best result.
I am NOT against that.

So maybe I am just getting a bit engeged in the precission of semantics...

But it is a bit important, as some preconceptions lead to unwanted results, and the blame is on the camera and not the signalchain. Kinda exactly why Jim warns about the current ACES implementation....

I am actually all for just grading/correcting off a RC3/RG3 whiteballanced image if that fits your deliverymedium, as there is sooooo much thought put into those tools.
Making priorities in your data is a good thing. Even better when you know what the different processes do to it.
And colorcorrecting is all about prioritaizing data. (In a pure technical non-artistically term...)

I am NOT for everyone allways doing stuff a hard way when it can be done easilly and through that actually better.

Just sayin...

 

[Jose Lomeña]

I run a lot of test, but I can't spent 10x times space and raid speed... and for what reason?, whats the advantage of transcode all?

What do you do with HDR, do you use "magic motion HDR"... do you like it?

 

[Gunleik Groven]

The advantage is basically consistency.
And that if you have the infrastructure, the turnaround is really reliable and fast...
And it is not for all. I agree
And we don't use it for all, because of the time/space saved by not doing it.

But there are good reasons to do it when we do it.
That's just my point.

Actually we follow different workflow and signalpaths for different kind of projects. And sometimes for different shots in the same project. VFX or not...

Some really simple
Some pretty "advanced"

Right workflow for the right productiontype/budget/ambition/shot.

And the result is what counts... Not religiously following a workflow...
Far from all productions are dynamically challenged. So why use a workflow for those that takes that aspect into consideration?

Message is basically:
Do what works best.

Not:
Allways do this or that.

And:
If it looks great, then you probably did something right...
If not:
Try to solve it.

If someone have been reading my posts on this subject earlier, I actually am a huge fan of Mark Toias approach... Which seems rather contradictory, right?
IMHO It is not.

What Mark forgets to communicate is basically how well he knows his tools and workflows...
And what a good photographer he is.
Not a humble man. But in this respect, he forgets to mention that he knows his basic craft pretty well...

HDR?

See the above.

When you start to recognize image clues in your shots that calls for some extra attention, you start really saving time... Because then everything else can be done very simplisticly with as good a result.

But enough now!!!

let's get this thread back to ACES!

(Geee... sometimes I miss Deanan more than other times! He'd be bitching all over me for this! )

The whole idea of ACES is to conform the signalchain.
I love that idea!
NOW: Make it work properly.

And my guess is that they will make that work properly... In a while.

 

[Erich Ocean]

In my opinion, If you convert to tiff 16bit, you loose:
1. Space
2. Raid or network speed
3. Color space
4. White balance too early
5. HDR not separate

I do this for vfx shots only. The rest RAW.

I don't think anyone is suggesting converting to 16-bit TIFFs. OpenEXR with mild compression is the industry standard in VFX, and frankly, a superb format. For edit-only footage (no VFX), you'd use ProRes4444 or the equivalent DNxHD format when it's available.

Setting color space and white balance is mandatory on any shot, and virtually always only needs to be done once. There's no reason not to do it "early". (This is why it can be done successfully in-camera on the Alexa without negative consequences.)

HDRx footage can be retained in the same way that stereo footage is now, if that's what you want.

RAW is great, but transcoding to a rock-solid RGB format from R3D (currently RedColor3/RedLogFilm) early in the pipeline is, IMO, the best way to work today. Keep the R3D files around as negatives if you ever need to go back to them, which in practice, will basically be "never".

File sizes stay low, and computational processing overhead is an order-of-magnitude better. This speeds up your entire production pipeline.

Case in point: I review edits on my quad-core iMac. I can easily play back 1080p footage in ProRes at full quality at 30fps. I can't play back the RAW 3K R3D footage at better that 1/8 quality smoothly (1/4 almost is there, but still stutters). And this is 3K! 4K and higher (I've got an Epic) are only tractable with a RedRocket, and as Bruce pointed out, who wants to buy a $5K RedRocket for every computer that reviews RED footage when you can buy one instead and transcode?

 

[Gunleik Groven]

Agreed (allmost...) on all points Erich.

And it is pretty efficient...

 

[Hrvoje Simic]

Improving consistency with RAW in a complex workflow can be done by enabling .r3d "lockdown"
which removes the ability of altering any of the settings.

Once the look and workflow standard have been decided and material pushed further in the workflow chain, variables are removed and risk minimized while maintaining material thickness, flexibility and data rates all the way until the necessary RGB transforms.

 

[Gunleik Groven]

Improving consistency with RAW in a complex workflow can be done by enabling .r3d "lockdown"
which removes the ability of altering any of the settings.

Once the look and workflow standard have been decided and material pushed further in the workflow chain, variables are removed and risk minimized while maintaining material thickness, flexibility and data rates all the way until the necessary RGB transforms.

And with this... I totally agree!

Predictability beats flexibility once things are done right...

 

[Jose Lomeña]

RAW is great, but transcoding to a rock-solid RGB format from R3D (currently RedColor3/RedLogFilm) early in the pipeline is, IMO, the best way to work today. Keep the R3D files around as negatives if you ever need to go back to them, which in practice, will basically be "never".

I'm sorry Erich but I disagree. You think that 1080p is good enough, I don't think so. I re scale a lot.
Tiff 5k or open exr 5k, try it yourself, how much space do you need per second?. Do you try proress444 more than 4k?, it is inconsistent, at least with davinci. And who use prores for vfx?... maybe someone.
And with HDR you want 2 files?... maybe I need a new raid capable of +2000MB/s?... with at least 100TB?... this cost a lot more than a redrocket or two.

Horses for courses... I transcode for vfx a lot, but if I can i prefer to have r3d when grading. If you think that transcode all is good, maybe for you... but not for all people. And is not the best way to work today, this is a way. Of course best for you.

 

[jake blackstone]

I happened to think, that the most flexible approach is to stay with the original signal for as long as possible, while carrying the necessary metadata with all color information, including color grading choices. One of the best examples is the Filmlight approach. They demonstrated their proposal by enabling editorial (FCP or Avid so far), VFX (Nuke) and obviously DI (Basielight) to exchange color information (XML plus EXR still for contextual reference)) without ever "baking in" the look. The workflow basically allows a pregrade or the look creation on a Baselight. Editorial can read that look, manipulate it, if needed and pass it along to the VFX. Nuke can work from the original files with the same look applied, while they create EXR. That shot get's dropped into the Baselight's timeline with the same look. No LUTs are used at any point, color decision flexibility is preserved for the whole duration of the workflow until the very end and no transcoding.