simple logC Prores conversion?

Hi - I'm a bit of a Resolve newbie, but trying to do something I think is fairly simple. Maybe you all can help me get where I need to be.

I have a timeline of Red Dragon footage over from FCP and have successfully imported the EDL and relinked.

All I want to do is run out a Prores 444 conversion of the timeline so it's not constantly debayering. I might swap back in the original Red for a couple of shots, but for the most part I think Prores would work much better and let me grade more interactively on my system, and with fine quality.

I need the Prores to be LogC (or even cineon would be ok) because I have some highlights I want to maintain.

No matter what I do, I can't seem to roundtrip these files and get them matching in After Effects or Nuke. It seems there's a gamma problem in my workflow that Resolve is introducing.

I thought the right way to go about it would be to add a 3d output LUT (linear to log). Also tried a custom LUT from the ARRI site to try to go Linear to LogC. No match.

What's the recipe to output a simple log prores?
I suspect it might have something to do with all of this in/out/timeline Rec709 working space, but not sure.

Thanks

ProRes is not expected to be in LOG mode, so this may be the reason. There is no such a thing like LOG singling in MOV headers, like with eg. DPX, but you still should be able to "pass LOG data with ProRes".
In Nuke you can try set input to RAW, so it doesn't try to apply any conversion. AE or NUKE just needs to read file as is- you know that it's in LOG mode.

ProRes444 is 12bit, so maybe there is no need to worry about highlitghs. I'm not that convinced that your source footage has enough useful informations in terms of dynamic range to "saturate" 12bit. You may not need LOG mode at all, as 12bit may be enough to hold all data. Do a test- export short clip with some HDR scene as "normal" ProRes444 and EXR. Import back and try to play with it (try strong corrections) and check if ProRes is really not holding up.

you might be overthinking it...

this is a workflow i commonly use;

in properties seleect general options
in general options select "cache frame in"
select prorez444

select all the clips on your timeline,
right click on any one of them,
select "render cache clip source",
select "user"

go to playback pull doen menu at the top
select "render cache"
select "user"

it will respect your de-bayer setting, so likely choseing Dragoncolor2 & Redlog film, turn DEB and DRX as needed before cacheing wil get you to a similar place as LogC

a red bar will appear on the top of the timeline, when it turns blue from one end to the other it's running off caches

if you really want to keep those highlights then the best option is to chose ACES and 16float for caches, but you will need alot more diskspace and speed when compared to just running the Dragon raw

And working in ACES takes a bit of seat time, and also likely the highlights wil be just fine in RedLogFilm

Your method is just a simple conversion to ProRes.
We want footage to be converted to LOG first than stored as ProRes, as this should preserve more dynamic range with 12bit in ProRes. It's not the same what you have described.

Original idea with applying LUT on export is good, but I don't think you can get perfect match to original footage.

Your method is just a simple conversion to ProRes.
We want footage to be converted to LOG first than stored as ProRes, as this should preserve more dynamic range with 12bit in ProRes. It's not the same what you have described.

Original idea with applying LUT on export is good, but I don't think you can get perfect match to original footage.

uhh... choseing redlogfilm does debyaer into traditional log.... no lut's needed, and no lut dammage as a resualt

Do you really want to de-bayer to RG4, and then use a lut to make RFL from that? Why?

If you debayer to LOG than you are correct. Nothing else is needed.
I think the point is to preserve as much usable data as possible inside ProRes444 capabilities (which may be actual able to keep all data without any tricks).

set debayer first redlogfilm.

done.

redlogfilm is equivalent to cineon

Thanks for the help.

Still trying to figure this out and wrap my head around how Resolve deals with this.

So the debayer settings on the Red clip come in at DragonColor2 and Redlogfilm, which looks nice except it appears to be soft clipping the highlights? If I scrub over the window in the scene in Nuke, I get values up around 4 and 5 on a 0-1 float scale. If I scrub over the same areas in Resovle, I get 241? Which would seem to be some sort of squeezed Rec709 white.

And then once I get my highlights back and am back to the full dynamic range, how do I get it to write a logC (or redlogfilm, or cineon) prores file? I'm not quite understanding, sorry. It seems very simple, so maybe there's a quick step by step you can give me so I see what I'm missing.

in nuke you are probably in linear light, is a different scale

Sure. In this case clamping my highlights would be quite destructive
Is there a way to work without the rec709 clamping that appears to be happening?
Can I switch the resolve timeline to linear with the full extended range outside 0-1?

Can I switch the resolve timeline to linear with the full extended range outside 0-1?

yea, but it''s not gonna be LogC or RFL encoded because that compresses dynamic range, and it's not gonna be PpoRez as that cannot contain full range data...

so if you drop the request for log encoded ProRez in favor of keeping the full dynamic range off the sensor, then;

project settings / master project settings / color science
switch to ACES
red raw is now linear, no de-bayer settings apply
export uncompresed float EXR

it's covered in the manual, most of the documentation for ACES is a trainwreck, but this actualy is covered accuratly and in some detail;

> When you’re rendering media for long-term archival, you should choose the OpenEXR RGB Half (uncompressed) format in the Render Settings, and set the ACES Output Device Transform to “No Output Device Transform.”

subsutute the words "long-term archival" with "vfx plates" and you'll be golden...

pg 156 or so...

R3D has to be debayered in order to be stored as EXR.

Sure. In this case clamping my highlights would be quite destructive
Is there a way to work without the rec709 clamping that appears to be happening?
Can I switch the resolve timeline to linear with the full extended range outside 0-1?

Just check if in case of RED RAW and ProRes you can get the same amount of information, by applying strong curves etc. Don't expect values to match- I don't think this will ever work.
I understand that you want to have R3D files "stored as ProRes444" and still be able to do the same amount of adjustments (so preserve all usable data). It will probably depend how much real dynamic range is stored in R3D. In some case 12bit ProRes444 may be able to hold it in others may clip.

I've done tests on some special HDR footage shot with 2xAlexa exposed for highlights and shadows (real 16 stops of DR) and ProRes444 wasn't able to hold it at all.

Sure. In this case clamping my highlights would be quite destructive
Is there a way to work without the rec709 clamping that appears to be happening?
Can I switch the resolve timeline to linear with the full extended range outside 0-1?

i respectfully disagree

no you are NOT clamping: the final range is just distributed in a different mapping.

if you debayer linear light and save the file in nuke as file A, then you do a red log film debayer in resolve, save a dpx out, grab in nuke and do a [COLORSPACE] cineon to linear, the two files will look really close with no clamping.

we do this kind of workflow all year around, it works, is proven

R3D has to be debayered in order to be stored as EXR.

yup, but it has no gamma or color settings in linear... you can still mess with color temp, deb, hdrx, on and on... but no option for dragoncolor2 / rfl as it's linear

i agree with Walter btw, and said that a few posts ago, likely there's little -to- nothing to be gained by going the ACES/EXR route, but the orignal post was on about maintaing highlights at all costs.. the option is there - if it's worth the price of admission, there no doubts about what the image holds if ACES & EXR are used

If he finds Dragincolor2/RFL/ProRez to be insufficiant for his workflow, the option is there...

wonder what is in the highlights that is worth the overhead of ACES/EXR workflow, i've not seen the need for that myself.. but if the VFX hosue asks for EXR, it's no sweat to provide them and i chearfully do

i respectfully disagree

no you are NOT clamping: the final range is just distributed in a different mapping.

if you debayer linear light and save the file in nuke as file A, then you do a red log film debayer in resolve, save a dpx out, grab in nuke and do a [COLORSPACE] cineon to linear, the two files will look really close with no clamping.

we do this kind of workflow all year around, it works, is proven

Yes, re-mapping has to happen, as you dealing with different precisions.

In the same time if file has huge dynamic range clipping will happen at some point (or in other words- you will have less data to do heavy adjustments). This is why you may want EXRs, so this will hold all what is in the R3D.

R3D has to be debayered in order to be stored as EXR.

yup, but it has no gamma or color settings in linear... you can still mess with color temp, deb, hdrx, on and on... but no option for dragoncolor2 / rfl as it's linear

i agree with Walter btw, and said that a few posts ago, likely there's little -to- nothing to be gained by going the ACES/EXR route, but the orignal post was on about maintaing highlights at all costs.. the option is there - if it's worth the price of admission, there no doubts about what the image holds if ACES & EXR are used

If he finds Dragincolor2/RFL/ProRez to be insufficiant for his workflow, the option is there...

wonder what is in the highlights that is worth the overhead of ACES/EXR workflow, i've not seen the need for that myself.. but if the VFX hosue asks for EXR, it's no sweat to provide them and i chearfully do

Yes, this is the point

Yes, re-mapping has to happen, as you dealing with different precisions. In the same time if file has huge dynamic range clipping will happen at some point (or in other words- you will have less data to do heavy adjustments). This is why you may want EXRs, so this will hold all what is in the R3D.

I see no practical, real-world benefit with working with EXRs or DPXs compared to ProRes 444, provided the R3D image files are decoded correctly and the DMIN and DMAX (exposure and ISO) and Color Temperature are set correctly. Do that, and there are no issues.

If cost and time are no object, then I'd gladly run camera raw files all day long. Unfortunately in my world, cost and time are always objects to deal with.

Yes, re-mapping has to happen, as you dealing with different precisions. In the same time if file has huge dynamic range clipping will happen at some point (or in other words- you will have less data to do heavy adjustments). This is why you may want EXRs, so this will hold all what is in the R3D.

I see no practical, real-world benefit with working with EXRs or DPXs compared to ProRes 444, provided the R3D image files are decoded correctly and the DMIN and DMAX (exposure and ISO) and Color Temperature are set correctly. Do that, and there are no issues.

If cost and time are no object, then I'd gladly run camera raw files all day long. Unfortunately in my world, cost and time are always objects to deal with.

agreed. there is this myth about the "raw" carry this amazing signal than the prores/dpx cannot even think to hold it.

not as such.

the"raw" file is a sort of j2k wrapped in a r3d box, the image is compressed and the data is what it is. ...

carry on.

Well- not really, as RED and Sony RAW files are 16bit and when people talk about DPX they mainly mean 10bit one. In theory these RAW files could hold a lot of data which could be "lost" during conversion to 10bit, but this is mainly theory. Even if they are 16bit I don't think any sensor out there can deliver real/usable data which doesn't fit in 12bit signal. I may be wrong, but people who work with these files every day should be able to confirm it. The fact that R3D files are 16bit is one thing, but what they're actually holding is another.

I have some EXRs made by German university with 2 Alexa exposed for highlight and shadows (test material for HDR study) and this definitely won't be preserved by 10bit codec/format. But this is not coming from a single sensor, but it's "processed" combined footage.

.

I have some EXRs made by German university with 2 Alexa exposed for highlight and shadows (test material for HDR study) and this definitely won't be preserved by 10bit codec/format. But this is not coming form a single sensor, but it's combined footage.

hdr night be more tricky. .. yes. but as you mentioned those are two combined images.
I'm not expecting to see much difference (if any) in the usable range of 12-13 stops exr vs will encoded raw.

there is also another consideration: your color grading will be waaay more big than the possible difference.

dpx log 10 or 16 bit is a perfect viable option, 1000th of movies are done every year.

exr linear light can be used for special cases.

.

I have some EXRs made by German university with 2 Alexa exposed for highlight and shadows (test material for HDR study) and this definitely won't be preserved by 10bit codec/format. But this is not coming form a single sensor, but it's combined footage.

hdr night be more tricky. .. yes. but as you mentioned those are two combined images.
I'm not expecting to see much difference (if any) in the usable range of 12-13 stops exr vs will encoded raw.

there is also another consideration: your color grading will be waaay more big than the possible difference.

dpx log 10 or 16 bit is a perfect viable option, 1000th of movies are done every year.

exr linear light can be used for special cases.

EXR needs to be 16bit because it meant to store linear light data, so not "prepared" for human eye. Once some gamma etc is applied than bit depth can be reduced and still hold useable data. Does this sound right?
There are advantages to keep this linear light (less conversion, possible problems etc) through the whole pipe, but for the cost of storage and bandwidth.

yes, your bandwidth will need to be very robust. and your system as well.

yes, your bandwidth will need to be very robust. and your system as well.

For not huge money and complication you can build a system with 10GBytes/s bandwidth. Problems start when you need a network with such a speeds.

and local working storage too.. i allow for 450gig per 20min film reel for caches when working in ACES, and that's 450g of pretty fast storage on SAS, but i run flims with this all day long lately

And this is now a far cry from the orignal poster who was haveing the following issues;

1) was looking for a RG4->LogC LUT in the belief that somehow starting with RG4 media and ramming it though a LUT into LogC would magicly retrive highlights.

2) and was looking at workflow that had RG4 debayered, rendered though a LUT to LogC to make new ProRez master media to grade from.

3) was haveing issues with highlights for vfx and could not find out how to render something that maintained the full range of data

hopefull all three have been sorted..
1) i don't think anyone belives that rendering RG4, then re-rendering with a LUT into LogC would in any way be better than setting debayer to RFL, and likely alot worse

2) now know about caches in Resolve so does not need to render intrmediate files

3) now knows how to pull EXR's that will maintain everything in the file, no questions

and also knows that doing so is likey wasteful and will gain nothing over ProRez444 or DNxHR444

hopefully....

i have pulled EXR's for VFX houses when asked, it's billed by the hour, the post up wants to sign off on it, then we are happy to export what ever is asked for and add the hours to the invoice.. total a call of production and the vfx house

i grade in ACES becasue the producer asks me to, and it goes quickly anyway, it starts out in a good place already so we make our scheduale, and it makes no diffrence to the machines i work on, or anything else in the pipeline other than VFX and open seq./titles

Thanks for the tips - have not had time to jump back in and finish testing but will report back. Have given me a good amount to think about.

Dermot - I wasn't looking for an RG4 to LogC lut - I was looking for a way to get access and maintain superbrights in Resolve. Sorry, it's far from intuitive for a (typically) Nuke user. But seems to be able to be done with the right combination.

Unless I misunderstand, caches are not a option as I'm spreading this film to 3 colorists (sorry, didn't mention) and working with Prores vs DPX/EXR is highly desireable, both in terms of file size and interactivity. I mean, file size will likely be larger than R3d but in terms of bang for the buck it seems like the best "non debayer" option. Everything really bogs at 6k, so I'm happy to compress to prores and take a slight quality hit in terms of actually being able to work. I have a fairly beefy system (3960x, 5 drive raid, titan-x) but 6k dragon files are just not fun any way you slice it. For what I can tell based on initial tests - I think Prores or XQ might be the way of the 6k world, but again my beef with switching so far is that it's gotta be log! I've got bright overexposed windows to the outside world, and slightly underexposed actors inside of an apartment, and I need all of that data for this to look good. I'll need to carefully soft clip and restore detail to the windows and carefully boost the rest of it - it's all gotta be there. Good times!

Surely I can sort this out with some more futzing and thanks again for the ideas.

Hi Walter,

Quick question. You wrote this on this thread a little while ago:

“if you debayer linear light and save the file in nuke as file A, then you do a red log film debayer in resolve, save a dpx out, grab in nuke and do a [COLORSPACE] cineon to linear, the two files will look really close with no clamping.

we do this kind of workflow all year around, it works, is proven”


I’m on a job. I debayered to Red log film, with DRAGONcolor2 and exported to DPX. I thought RedLogfilm export dpx as cineon, not linear curve. However, the Nuke guys are telling me my DPXs are linear. Imported DPXs into AE using cineon color space and DPXs look correct, but it doesn’t look correct in Nuke until the say they use linear.

Now the manual does say “an improved gamma setting that’s designed to remap the original 12-bit R3D data to the standard Cineon gamma curve.”

Strangely, resolve says the red files are 10 bit, 5K 4700x2700. Not sure why 10 bit. Red Cine does provide me any metadata on the bit depth of the files. Does the bit depth matter in the remapping?

Other strange part of export is that I had to export as single clip, instead of a source clips. So I’m essentially exporting from the timeline. They shot 48 frames a second but don’t have the time for VFX on all 48 frames. So I speed up each clip 200% to the correct playback rate for 23,98 and essentially exported every other frame.

RCM is off, no grades, just the red debayer settings, and exporting from timeline. What am I missing? I know nothing about Nuke.

Thanks for your regular postings on color science.

I’m on a job. I debayered to Red log film, with DRAGONcolor2 and exported to DPX. I thought RedLogfilm export dpx as cineon, not linear curve. However, the Nuke guys are telling me my DPXs are linear. Imported DPXs into AE using cineon color space and DPXs look correct, but it doesn’t look correct in Nuke until the say they use linear.

if you did not do any color transformation and you used redlogfilm they are redlogfilm (cineon like).

I will question the settings in nuke.

can you pm me a single frame?

I’m on a job. I debayered to Red log film, with DRAGONcolor2 and exported to DPX. I thought RedLogfilm export dpx as cineon, not linear curve. However, the Nuke guys are telling me my DPXs are linear. Imported DPXs into AE using cineon color space and DPXs look correct, but it doesn’t look correct in Nuke until the say they use linear.

if you did not do any color transformation and you used redlogfilm they are redlogfilm (cineon like).

I will question the settings in nuke.

can you pm me a single frame?

the two files you send to me are LOG. (most likely RedLogFilm)

in Nuke they look somewhat ok if I flag them Cineon (redLogFilm=Cineon in nuke).

definitely they are NOT Linear light, nor gamma encoded (like 709/2.4)

Hey Walter,

Thank you for checking. The Nuke guys were able to return the footage in the same colorspace. Somehow they swear it's linear. I think I have to learn more about importing and setting up Nuke projects. Usually I just check my LUTs in AE.

Thanks again. Love your posts.