Output LUTs as a delivery preset option ?

Hello !

Since I'm using Resolve more as a conforming and finishing tool for my VFX needs, I was thinking that it would be great to have VFX LUTS (or any LUT for that matter) available as a preset option in Delivery page. So that let's say "Rec709 to Linear" LUT I'd just simply select as an option while exporting EXRs and have such preset saved, instead having to apply it and de-apply it globally on Output each time I need to export something.

What do you guys think ? Do you think having ability to add LUTs in delivery page would be good idea?

I prefer Color Management to LUTs.

I prefer those things be done on the Color page (or globally).

Not a good idea.

Bad idea.

Can you guys elaborate why would that be a bad idea? Even if it's just for VFX tech LUTS ?

Because you want to use an ODT instead.

What kind of workflow are you talking about here specifically?
What source material? And why to EXR? To what color space and transfer function?

Asking this because VFX IO LUTs from Resolve only convert gamma not gamut. This can get messy in management. A better way would be to export source camera native to .dpx and handle conversion in comp unless you are working in ACES where setting the output to "No Transform" a.k.a AP0/Linear will give you proper EXRs.

What kind of workflow are you talking about here specifically?
What source material? And why to EXR? To what color space and transfer function?

Asking this because VFX IO LUTs from Resolve only convert gamma not gamut. This can get messy in management. A better way would be to export source camera native to .dpx and handle conversion in comp unless you are working in ACES where setting the output to "No Transform" a.k.a AP0/Linear will give you proper EXRs.

EXR because we're using DWAA/DWAB compression, as so many plates these days are in crazy resolutions coming in, yet output is mostly HD, sometimes 4k. And because EXRs are expected to be linear, I apply Rec709 to Linear lut and export them as such - of course making sure everyone understands that viewing lut is Rec709, not sRGB.

What I'm doing is conforming timelines in Resolve and exporting to EXR so that's why I was thinking that maybe it would be easier to have such preset with selected LUT saved so I wouldn't have to make sure I apply it globally and then turn it off.

If all your material is shot in Rec.709 (the image appearance being normalized SDR) and not raw or some form of camera log encoding then that is the way to do it I guess. If it's not then the entire workflow is incorrect.

As to your approach, there is no other simpler way to do Rec.709 gamma to linear than using a LUT on your timeline I think. Solving it in a Color Managed setup would require the same amount of steps.

Adding it as option on export is very bad practice I'd say. Not only because it creates confusion to output settings but also heavily depends on the project color management and type of LUTs to make some sense having it there.

The only thing that would make sense is an assignable Output Color Space for RCM and ACES managed projects so it can be attached to export presets and don't need to be switched on the project settings.

I would rather prefer what Shebbe said. Select the desired output color space in the render settings in RCM2 or ACES projects, so you don't have to manually change the project settings everytime you export VFX.

This might even come in handy with multiple delivery outputs, like PQ, P3, HLG etc.

I mean it would be great to have it as an option.
Would be great to have an ACES Transform / CST option there also

I mean it would be great to have it as an option.
Would be great to have an ACES Transform / CST option there also

That's all I'm asking - ACES projects are different things entirely, but regular post-grade projects are most often what we're working on - and I wanted to move whole pipeline into EXR DWAA era as quite often we have to export full res plates from newest cameras and DWAA saves tons of space.

Would just love that color tag and gamma tag would be doing something actually.

I think it's dangerous to have the ability to add a transform in a render-only Deliver Page. What's wrong with adding a node to the Colour Page? It's the same amount of work and keeps all colour transforms in one page.

It's the same amount of work and keeps all color transforms in one page.

Yup.

I like that we can't change the program on the Delivery page. I think that should stay.

I disagree.

sometimes a 2.2 gamma out is required rather than 2.4 (or in addition to), going out ACES linear or camera space for VFX specific pulls - it would be nice to have it on the delivery page for single renders.

The tone mapping option is there and used all the time for HDR projects, so why not expand on those options?

As I understand it, what Pavle requests is a separation of view transform from output transform, as it has been in comp softwares for decades and is an essential part of the workflow. Why Resolve does not have this is beyond me.

As I understand it, what Pavle requests is a separation of view transform from output transform, as it has been in comp softwares for decades and is an essential part of the workflow. Why Resolve does not have this is beyond me.

Oh Hendrik, you always get what I'm saying

I think it's dangerous to have the ability to add a transform in a render-only Deliver Page. What's wrong with adding a node to the Colour Page? It's the same amount of work and keeps all colour transforms in one page.

it's equally as dangerous as having the option to render a "Flat Pass" and still that one is there. for good reason. and both options would be even used in the same context.

I think it's dangerous to have the ability to add a transform in a render-only Deliver Page. What's wrong with adding a node to the Colour Page? It's the same amount of work and keeps all colour transforms in one page.

Not necessarily, sometimes you need to render the same timeline multiple times with different gammas/colour spaces, or sometimes many timelines that need rendering out with a specific transform just for that output. Going through each and updating it after the render can take a while.

I think this would be a great addition to the delivery page.

- would also be good to be able to disable specific tracks for rendering to help with textless deliverables, but thats another thing :p

I think it's dangerous to have the ability to add a transform in a render-only Deliver Page. What's wrong with adding a node to the Colour Page? It's the same amount of work and keeps all colour transforms in one page.

Not necessarily, sometimes you need to render the same timeline multiple times with different gammas/colour spaces, or sometimes many timelines that need rendering out with a specific transform just for that output. Going through each and updating it after the render can take a while.

I think this would be a great addition to the delivery page.

- would also be good to be able to disable specific tracks for rendering to help with textless deliverables, but thats another thing :p

I think we could agree that having such options would help certain workflows a lot. I'd rather have options than not, personally.

Not necessarily, sometimes you need to render the same timeline multiple times with different gammas/colour spaces, or sometimes many timelines that need rendering out with a specific transform just for that output. Going through each and updating it after the render can take a while.

I suspect most colourists would not allow an output of something they could not check first on a reference monitor.

Having said this, Cullen Kelly illustrates a use for what the OP is suggesting - He uses a YouTube/FrameIO LUT that comes after the display output transform in a node-based color managed workflow (where the camera->CST->intermediate->grade->CST->display are in the node graph for each clip rather than using Resolve's project level RCM). The YouTube/FrameIO LUT is placed AFTER the CST->display output transform (which is why RCM can't be used).

However, if Resolve provided the ability to add an addition level of processing at the delivery level (sort of like a post-timeline level) then things like this YouTube/FrameIO LUT could be incorporated.

I'd rather have this as an option on the color page, though, but that would mean that it would have to be post RCM which in the OP's case would mean that RCM could not be used (my guess) and that a manual approach would be required.

Sorry for the long post - not enough coffee (yet).

I suspect most colourists would not allow an output of something they could not check first on a reference monitor.

This would mean that only things colorists ever produce are display referred. No linearized data for vfx, no log encoded files, no XYZ data for DCP, nothing outside their ref monitor. In practice it really isn't the case. How it should work is that you check stuff through view transform, but output transform is applied according to what you need to write. Changing view transform to do that as it is now, does not make checking any better (you can't check colorspaces that your ref monitor does not support) and workflow any easier, quite the opposite.

I suspect most colourists would not allow an output of something they could not check first on a reference monitor.

This would mean that only things colorists ever produce are display referred. No linearized data for vfx, no log encoded files, no XYZ data for DCP, nothing outside their ref monitor. In practice it really isn't the case. How it should work is that you check stuff through view transform, but output transform is applied according to what you need to write. Changing view transform to do that as it is now, does not make checking any better (you can't check colorspaces that your ref monitor does not support) and workflow any easier, quite the opposite.

Yep - I agree with this, in general, however, if you output to a narrower color space than you graded-in, you run the risk of not getting what you hoped for. You are correct that there are workflows where changing the output to something you don't actually view are called-for. Of course, there's nothing stopping you from doing this now in Resolve. The OP is just suggesting an additional option to focus this as part of a delivery configuration. I get it.

I think we were initially discussing the option of having your LUTs available on export. It's even in the thread title.

Maybe what Pavle meant was actually managed output transform options for RCM or ACES which I'm totally up for. But the actual LUTs on export is the worst thing I can imagine. While LUTs are very powerful when used properly, their purpose or origins can be incredibly vague. Especially if you don't create or manage them yourself. A dumb example is I've seen someone using the Sony SLog3 to Rec.709 LUT from Resolve to color grade under. But this LUT is just a conversion of the log encoding to gamma 2.4. No primaries conversion, no rendering intent. I can say: "well, the person in question should've just known better. We shouldn't dummy proof software", but the pitfalls of LUTs on export is just too big.

Managed output transforms on the other hand will always output whatever you tell it to output. And if it doesn't, it means you messed up in the management itself already. Not your export settings.

So yea, totally vote in favor of selectable RCM and ACES transforms on the delivery page. But LUTs I deem too risky. For most use cases like the one from Pavle it's pure technical to prep for VFX. You don't need LUTs to do this task.

Exactly.

I think we were initially discussing the option of having your LUTs available on export. It's even in the thread title.

Maybe what Pavle meant was actually managed output transform options for RCM or ACES which I'm totally up for. But the actual LUTs on export is the worst thing I can imagine. While LUTs are very powerful when used properly, their purpose or origins can be incredibly vague. Especially if you don't create or manage them yourself. A dumb example is I've seen someone using the Sony SLog3 to Rec.709 LUT from Resolve to color grade under. But this LUT is just a conversion of the log encoding to gamma 2.4. No primaries conversion, no rendering intent. I can say: "well, the person in question should've just known better. We shouldn't dummy proof software", but the pitfalls of LUTs on export is just too big.

Managed output transforms on the other hand will always output whatever you tell it to output. And if it doesn't, it means you messed up in the management itself already. Not your export settings.

So yea, totally vote in favor of selectable RCM and ACES transforms on the delivery page. But LUTs I deem too risky. For most use cases like the one from Pavle it's pure technical to prep for VFX. You don't need LUTs to do this task.

In principle I agree with you Shebbe - I shouldn't have to use LUT to be able to properly export EXRs from Resolve. And I agree - it would be much easier for me if colorists would use RCM or ACES exclusively. But when they use Resolve's non color managed workflow, I still would love to be able to export such plates straight to EXRs with proper linear transform straightaway.

I'm using Resolve differently than what it was designed for probably, but then again, it's a different application than it was originally - now with Fusion, Fairlight and other things embedded. What I would wish for is for Resolve to expand its conform and export options bit more - like having timeline clip batch renaming for example, more options whether I'd like to export retime'd or non-retimed.

Simply, I'd believe Resolve would benefit from having more options similar to Hiero.

I agree with you there.

The fact that Fusion isn't even color managed properly in RCM/ACES is enough reason to not want to use project wide management. The problem with Fusion is that it was never designed to be in the first place. You always set it up yourself and you can even decide when you want to work in a particular bit depth where as Nuke is always color managed through OCIO and 32bit float.

As I understand it, what Pavle requests is a separation of view transform from output transform, as it has been in comp softwares for decades and is an essential part of the workflow. Why Resolve does not have this is beyond me.

That also ties in to this statement. I don't think there are any other comp software where there is 'no management'. You always use their built in transforms/management or OCIO. Not some limited list of questionable LUTs.

Perhaps to a degree it could make sense to add a CST like transform option on export. The problem with the CST node however is that depending on how you use it, it's totally different things. It can be straight technical conversions, it can be a tone mapper, gamut mapper, use chromatic adaptation or not, use forward/inverse OOTF. It does too many things and only adding in the color space list on the delivery page would be confusing to say the least. Which of the above should or should it not do? Should all CST settings be exposed? Probably even more confusing and annoying to set up.

If I had the power to redesign Resolve I would totally tear the CST apart and have dedicated display transform nodes for DaVinci DRT or other tone mapping and gamut mapping options (even add IPP2 in) and leave the color space transform pure as technical transform there. Then this could easily be exposed on the delivery page as well without any ambiguity.

On top of that I would add OCIO to serve as global management for both Resolve Color and Re-Fusion so everything talks nicely as it should, provide the same proper dipslay/view in Fusion as in Color, and also add the OCIO color space list on Delivery Page for conversion on export.

This would solve so many things for so many workflows. But I think BMD doesn't care enough and want to shove RCM/DaVinciDRT enclosed management too much up our buttocks even though it's broken in many ways.

On top of that I would add OCIO to serve as global management for both Resolve Color and Re-Fusion so everything talks nicely as it should, provide the same proper dipslay/view in Fusion as in Color, and also add the OCIO color space list on Delivery Page for conversion on export.

This would solve so many things for so many workflows. But I think BMD doesn't care enough and want to shove RCM/DaVinciDRT enclosed management too much up our buttocks even though it's broken in many ways.

OCIO would solve so many things - to be honest, I know I'm setting up myself for impossible challenges sometimes, but every time I tried to use Hiero seriously, I just feel I'm wasting so much time. Right there on the beginning with how Hiero understands XML/AAF timelines, when I import most of the timelines I'm asked to conform, it's straight up mess. While Resolve has this part mostly nailed down. I'd say Hiero is there ~30%, while Resolve is 90-100% with just aligning clips with offline reference.

Maybe OTIO would save us from this madness one day - but then again, there is no OCIO in Premiere/After Effects so I doubt there will be OTIO.

Maybe OTIO would save us from this madness one day - but then again, there is no OCIO in Premiere/After Effects so I doubt there will be OTIO.

Adobe might be on a small redemption arc here..
https://community.adobe.com/t5/after-ef ... p/13277082

But yea they have a long way to go too. At least they're finally recognizing the needs of their users. With a lot of other upcoming updates too and v23 of AE that released recently.

Maybe OTIO would save us from this madness one day - but then again, there is no OCIO in Premiere/After Effects so I doubt there will be OTIO.

Adobe might be on a small redemption arc here..
https://community.adobe.com/t5/after-ef ... p/13277082

But yea they have a long way to go too. At least they're finally recognizing the needs of their users. With a lot of other upcoming updates too and v23 of AE that released recently.

I'm rooting for them only because so many editors lately here in Poland are starting to use Premiere instead of Avid (if not just Resolve, which would be most logical choice in my opinion, in TVC field).

This would solve so many things for so many workflows. But I think BMD doesn't care enough and want to shove RCM/DaVinciDRT enclosed management too much up our buttocks even though it's broken in many ways.

I think that's unkind and unfair. The fact that you can not use any color management at all, or use custom color management on a node-by-node basis, or you can use ACES, or you can use RCM is enormously flexible. At least Resolve gives you the power to use whatever you want and work in whatever method suits you.

Agreed, but I chuckled over the 'buttocks' comment, lol.

You can go from your camera “log” to linear EXR and back using [color space transforms] we do it all the time for vfx (you can also make DCTLs if you like for the same purposes,

Color space transforms and DCTL, they have full 32bit precision, instead a LUT is bound to approximation and it is a BAD idea if you go form linear light back to camera log.

Depending on the VFX company you work with, they might require camera linear or ACES, the proces is similar but the primaries are different.

Let’s just make the simpler case of camera linear.

1) debayer the shot as you wish in camera log, that is, Alexa LogC3 if it is an Alexa, SonySlog3.cin e if sony and so on
2) use a CTS and set is as: [alexa logC :: alexa log C :: Alexa log C:: Linear] then set EVERY OTHE PARAMETER of the CTS to null/untag/none
3) export as EXR.

In import, bring the EXR in and add a CTS as [alexa logC :: Linear :: Alexa log C:: Alexa LogC] then set EVERY OTHE PARAMETER of the CTS to null/untag/none

And you should get back the shot as it was minus the compression of the EXR and the imprecision of the 16 float vs 32 full…

Luts differ in their accuracy, whether they 17point, 33point etc. They are for 'decompressing' the log for viewing, editing and grading. A finishing editor does not 'allow' or 'disallow' anything - they deliver to hopefully accurate fixed specifications. Colour managed workflows like Aces are designed to make that process easier and more accurate from the same timeline/version. Packages like IMF exist to contain multiple essence at multiple colour spaces, SDR, HDR etc. To deliver in log and then supply various 3D Luts, is not finishing and doing only half the work. It's cumbersome and confusing for the recipient also and despite the cases made, I can see no use for it - you could simply deliver the camera original log, with whatever Lut you want as a separate side car, without the need of a specific export option, as do the camera rushes arrive in the first place.

You can go from your camera “log” to linear EXR and back using [color space transforms] we do it all the time for vfx (you can also make DCTLs if you like for the same purposes,

Color space transforms and DCTL, they have full 32bit precision, instead a LUT is bound to approximation and it is a BAD idea if you go form linear light back to camera log.

Depending on the VFX company you work with, they might require camera linear or ACES, the proces is similar but the primaries are different.

Let’s just make the simpler case of camera linear.

1) debayer the shot as you wish in camera log, that is, Alexa LogC3 if it is an Alexa, SonySlog3.cin e if sony and so on
2) use a CTS and set is as: [alexa logC :: alexa log C :: Alexa log C:: Linear] then set EVERY OTHE PARAMETER of the CTS to null/untag/none
3) export as EXR.

In import, bring the EXR in and add a CTS as [alexa logC :: Linear :: Alexa log C:: Alexa LogC] then set EVERY OTHE PARAMETER of the CTS to null/untag/none

And you should get back the shot as it was minus the compression of the EXR and the imprecision of the 16 float vs 32 full…

Yeah well if that would be the case for projects, I just simply convert everything to ACES-2065 from Resole and export that - because it's most safe and simplest method of preserving whatever log flavor someone delivers to me, and I also don't have to export many LUTs and wrangle with VFX software to show artists properly display transferred image. ACES solves that, but it only works if I can work before colour grading is applied. Sometimes turnarounds are so tight that I'd rather export Rec709 Linear EXR and have people working with that, as long as color correction isn't something crazy colour and effects wise.

Then once you deliver 709, you don't even need exr, the precision is already gone and it is an unnecessary complication.

Dpx10 bit as is, exr as is, or prores 444 are good enough for that kind of workflow.

Remember that you will compress the signal at the end for distributions, so don't sweat too much about it.

Then once you deliver 709, you don't even need exr, the precision is already gone and it is an unnecessary complication.

Dpx10 bit as is, exr as is, or prores 444 are good enough for that kind of workflow.

Remember that you will compress the signal at the end for distributions, so don't sweat too much about it.

Except DPX doesn't have any compression method, and it doesn't care if it's a black empty frame or full-blown plate - it always has the same amount of data on a drive. Also, since so many DOPs jumped into large format bandwagon so hastily, that also means that we're receiving 3:2ish aspect ratio frames, while delivery is HD mostly. So, in order to preserve that, it's much easier for us to export grading in EXR DWAA/DWAB in source resolution and let the conforming fella figure out with supervisor what's best for particular project.

Just for comparison - 4.5k from Alexa LF is around 50mb in DPX, 33 mb in EXR ZIP and 12mb in DWAA. You do the math.

Also - EXRs do transfer a lot of metadata which comes in handy later on in VFX.

This would solve so many things for so many workflows. But I think BMD doesn't care enough and want to shove RCM/DaVinciDRT enclosed management too much up our buttocks even though it's broken in many ways.

I think that's unkind and unfair. The fact that you can not use any color management at all, or use custom color management on a node-by-node basis, or you can use ACES, or you can use RCM is enormously flexible. At least Resolve gives you the power to use whatever you want and work in whatever method suits you.

Ok maybe a bit harsh, but my reasoning comes from the fact that they integrated Fusion into Resolve which offers OCIO yet you can't utilize it outside of it. Neither can you have it operate on a global level within Fusion like in Nuke for example. And the same goes the other way around. You can't properly use RCM and Fusion at the same time. Neither can you with ACES. Maybe I wouldn't have made that comment if things were just working as they should... it's frustrating to me at least.

This would solve so many things for so many workflows. But I think BMD doesn't care enough and want to shove RCM/DaVinciDRT enclosed management too much up our buttocks even though it's broken in many ways.

I think that's unkind and unfair. The fact that you can not use any color management at all, or use custom color management on a node-by-node basis, or you can use ACES, or you can use RCM is enormously flexible. At least Resolve gives you the power to use whatever you want and work in whatever method suits you.

Ok maybe a bit harsh, but my reasoning comes from the fact that they integrated Fusion into Resolve which offers OCIO yet you can't utilize it outside of it. Neither can you have it operate on a global level within Fusion like in Nuke for example. And the same goes the other way around. You can't properly use RCM and Fusion at the same time. Neither can you with ACES. Maybe I wouldn't have made that comment if things were just working as they should... it's frustrating to me at least.

I agree with you on this matter - sadly, from what I've seen they promote fusion as some kind of motion graphics title generator, while back in the day it was Nuke before there was Nuke (if you weren't using Shake).

Then once you deliver 709, you don't even need exr, the precision is already gone and it is an unnecessary complication.

Dpx10 bit as is, exr as is, or prores 444 are good enough for that kind of workflow.

Remember that you will compress the signal at the end for distributions, so don't sweat too much about it.

Except DPX doesn't have any compression method, and it doesn't care if it's a black empty frame or full-blown plate - it always has the same amount of data on a drive. Also, since so many DOPs jumped into large format bandwagon so hastily, that also means that we're receiving 3:2ish aspect ratio frames, while delivery is HD mostly. So, in order to preserve that, it's much easier for us to export grading in EXR DWAA/DWAB in source resolution and let the conforming fella figure out with supervisor what's best for particular project.

Just for comparison - 4.5k from Alexa LF is around 50mb in DPX, 33 mb in EXR ZIP and 12mb in DWAA. You do the math.

Also - EXRs do transfer a lot of metadata which comes in handy later on in VFX.

I still think you are overthinking this.

Either you do the VFX before color (preferred) then you use either camera LOG or linear light. But I understand that not always is possible, then, you use some lighter format like prores 444 XQ, EXR seems overfilled and prores can keep both tape ID and Timecode.

However, if you really like compressed EXR, then I dont see what the question is about: color, then export EXR and be marry!!

Most of the discussion still evades the root question of why Resolve doesn't allow separate view and delivery output transforms. How these transforms are defined or what format is written out exactly is irrelevant.

Most of the discussion still evades the root question of why Resolve doesn't allow separate view and delivery output transforms. How these transforms are defined or what format is written out exactly is irrelevant.

This - if there's an option for a Output LUT in color management, there should be some kind of information in Resolve about it - otherwise if I forget to turn it off, someone is in world of suprise. And what I should be able to do is to export however I need to in delivery tab. Exporting EXRs in Rec709 are confusing.

maybe its not a separate view and output but what you call „delivery preset” is a simple switch of output in color managment part of color settings: shift+9, pick output type, save, have a quick look at frames on Delivery page if it looks as it should and send it. At least with ACES everything seems to work ok. Only the Fusion view lut needs to be set manually.

maybe its not a separate view and output but what you call „delivery preset” is a simple switch of output in color managment part of color settings: shift+9, pick output type, save, have a quick look at frames on Delivery page if it looks as it should and send it. At least with ACES everything seems to work ok. Only the Fusion view lut needs to be set manually.

Yeah I know but this works only if colorist after which I'm getting project from is using Resolve Color Managed or ACEScc - most of the time they are using regular Resolve YRGB.

I'm imagining that with EXR as a format selected, it would be awesome to have an extra option there to convert it to linear gamma for further work.

But the really solution I'm seeing is to work more in ACES or hybrid ACES way (LOG > ACES (VFX in ACES) > LOG). That way I'm also free from whatever happens on color grading.

maybe its not a separate view and output but what you call „delivery preset” is a simple switch of output in color managment part of color settings: shift+9, pick output type, save, have a quick look at frames on Delivery page if it looks as it should and send it. At least with ACES everything seems to work ok. Only the Fusion view lut needs to be set manually.

Yeah I know but this works only if colorist after which I'm getting project from is using Resolve Color Managed or ACEScc - most of the time they are using regular Resolve YRGB.

I'm imagining that with EXR as a format selected, it would be awesome to have an extra option there to convert it to linear gamma for further work.

But the really solution I'm seeing is to work more in ACES or hybrid ACES way (LOG > ACES (VFX in ACES) > LOG). That way I'm also free from whatever happens on color grading.

Are you using timeline-level part of Color tab? This might be fairly comfortable for final color space transforms.

But the really solution I'm seeing is to work more in ACES or hybrid ACES way (LOG > ACES (VFX in ACES) > LOG). That way I'm also free from whatever happens on color grading.

I see a lot of VFX company using this approach....

But the really solution I'm seeing is to work more in ACES or hybrid ACES way (LOG > ACES (VFX in ACES) > LOG). That way I'm also free from whatever happens on color grading.

I see a lot of VFX company using this approach....

It's kind of default for any feature film & episodic VFX, but not that common in commercials - but it's my job to spread the information in my facility and convince everyone to use better tools and workflows.