DNG import into NUKE possible?

Hello, I wanted to see if BMD would / or is in talks with the foundry to get the DNG files from the BMCC into Nuke. R3D support is in there now and it would be pretty nice.

Until Resolve gets a good denoise solution Nukes really kicks but and for the highend users doing compositing it would be nice to denoise and prep footage this way with the full range DNG files.

I was playing around with some noisy DNG samples and Nuke really cleaned them up to the point Im not even worried about it with the BMCC.

Use J_Ops which includes J_rawReader and allows direct reading of .dng (as well as other raw formats) into nuke.

http://www.nukepedia.com/plugins/other/j_ops/

-gary

Awesome, I'll try it when I'm back at work after the holidays. We have it installed but never thought to try that. I'll talk to the guys at the foundry when they come by too, it would be nice to have import and controls like an r3d or close to it.

On another note even in resolve there was only 3 values in the camera raw section. I don't have the camera yet but from test files it didn't seem to have a lot of info in there like meta data. Maybe it got stripped out..

Using "Shot 5" from the Afterglow DNG sequences, I'm attempting to import the full range of a DNG into Resolve Lite and export as a "scene-referred" high dynamic range linear float openexr image to read into Nuke.

Initially, to avoid adding Resolve into the mix, I tried importing directly into Nuke with J_Ops but probably because of the custom log curve which J_Ops doesn't know is applied to the footage, it's not giving me the same result as Resolve. Basically I set colour space to "raw" (not srgb) and "blend highlites". It does a good job but in addition to not being "BMD log-aware", the rawlib library it uses is not really aware of possible floating point values in an image above 1 (it outputs a 16 bit integer image under the hood), so it's creating an underexposed image.

Using Resolve instead, this is what I've tried with some success so far:

DNG Settings/Master Settings (I don't know Resolve that well and it seems I need to set the same thing in two separate locations? I'll have to RTFM):
Decode using: Clip (counter intuitive when you don't want to clip any data)
ColorSpace: Rec709
Gamma: Linear

Render to OpenEXR (16 bit half), unscaled full range data.

Importing into Nuke just as a regular linear exr, I'm getting what looks like a visually identical or extremely similar image to what I see in the Resolve viewer when I set the colour space and gamma to Rec709 in the master settings. Like Resolve, the dynamic range has been expanded so that my highlites now have values over 4 which isn't too bad at all, but considering the brightest values are coming from the sparklers I would imagine they are way off what an Alexa or a film scan would have captured. It's possible that I haven't imported the footage correctly, that it's not truly linear and maybe the highlites do go up to 11 or something but if this is what you get, and the image is indeed linear then it's still pretty damn cool for this price.

The only issue I'm seeing is that when I pull the exposure value down in Nuke or Resolve, yes it is revealing a lot of blown out detail in the sparkler but it's also showing the magenta clipping at the brightest core of the highlight.

I haven't checked yet whether Resolve is grading in a true linear space by doing a comparison with Nuke. I'm guessing that with the full version of Resolve, the LUT workflow can be set up so that I can colour correct in linear space, or log (like a DI) if I want while viewing correctly on an srgb, Rec709 or P3 monitor (like Nuke). It still seems like a bit of a headache compared to Nuke's workflow in this area.

So overall, using Resolve seems at minimum, an essential "ingest" stage for BMD footage destined for compositing. Firstly to transcode the DNG's to a fast, usable format (zip compressed half float exr's) and to get (hopefully) true linear float images.

What would be a nice option is to be able to invert the log LUT in Nuke, since you can transcode the DNG's in Resolve but retain the "BMD Film" log encoding when importing, then save them into 10 bit dpx files. In Nuke I tried an approximation of the LUT embedded in the CinemaDNG which was mentioned here, http://forum.blackmagicdesign.com/viewtopic.php?f=2&t=2910&start=20#p18863, on "BMD Film" renders of the footage straight from Resolve, but no luck. So it would be great if we could get that LUT put out there officially, following the example of log-c, s-log, etc.

Also, the ability to convert BMD-log to Cineon log in Resolve, since Cineon log is great for certain types of grading in a DI context. Again, probably possible in the full version of Resolve.

Cheers,
Michael

I'll have to read your response closer when im not at work but I wanted to let you know my findings with getting full range in nuke using Alexa footage.

At the studio we have mainly been using an SRGB / linear pipeline in 3d (Maya and Houdini) and 2d (Nuke) but when everyone started using the Alexa we had an issue with this clipping you are talking about. From talking to Deke at the foundry it seems like non LOG colorspace settings in Nuke will always clip above 1. This means that even if its a 16bit tif, 32bit float exr it will give you the magenta clipped highlights. Because we always need to delivery the plates exactly how we get them this was obviously a big issue.

The solution: if you are not going to import DNG files in Nuke then I would export DPX files from resolve with a cineon or logC colorspace. This for us anywys has maintained all the data through the pipeline. Now to export for the 3D team we will to tiffs and jpg's in linear or srgb so they can work with them but always LogC in Nuke.

I will have to look at the differences in Resolve and Nuke to see how I will work with the DNG files but I do like the denoiser in Nuke and the advanced grain node available on Nukepedia is unmatched by anyone for adding film grain. I dare say I could match any type of grain with that node....AnYTHING

That's interesting that you're saying Alexa footage gets the clipped highlights in Nuke when you read it in. I assume you mean you still get a lot of values above 1, but that if you gain down you can see the magenta clipping in the brightest highlights. Yes, only linearised log and 32 bit float formats will have any values above 1 unless it's a Raw image, in which case there are potentially some highlights above 1.

I've worked on some Alexa shows and we got the plates as exr's with a massive amount of dynamic range so they've been ingested and converted to linear beforehand. I've worked with 2k downconverts and the original 2.8k(?) plates for certain things like reprojection. I've not read the Alexa raw image directly into Nuke though.

Yes it seems possible that keeping the BMD footage as log would maybe fix this issue, but then again it's probably a limitation of the sensor so it wouldn't matter what you transcoded it to. Hopefully I'm wrong. It's basically the same issue I've seen with a Canon Raw image creating magenta highlights, although we weren't able to extract values higher than around 1.2-1.5 (using some raw-fu) even though that's a 14 bit sensor.

If we did export the DNG's as log, since we don't have BMD log curve available (yet), I'm assuming in the full version of Resolve that I could somehow go from the BMD log to some other log that has a known curve you can use in Nuke, and resolve would internally go BMD log>linear>Cineon log (for example). Otherwise, we're still not getting an exact mapping of the sensor data for when it's linearised in Nuke.

No no lol I may have written it in a confusing way. We don't get any data loss on Alexa plates. No highlight clipping or anything as long as you use the LogC or cineon colorspaces. If you read in a dpx as logC you will be able to recover or stop down the viewer and see that it is there. But as soon as you try to write it back out with any other colorspace like srgb, rec709, linear, it will clip any give you magenta or grey clipped highlights. This even happens with full float 32bit exr files. I've confirmed this with Arri and the foundry. It has to do with the way the inverted log curve stays bellow 1 and then when the lit is applied it inverts back to values well above up to 16+

On and I have not worked in Arri raw but just getting dpx files from post which in the camera they were shooting to SxS so the compression is a whole other thing we are fighting to change on set. Nothing like getting compressed footage for green screens lol

To the lay person, if you're working with high dynamic range footage from a camera like the Alexa or even 35mm, you need to be using a LOG pipeline in order to maintain that data until you're ready for delivery. This a standard VFX pipeline for Cinema at the major studios worldwide.

Since Linear only supports values between 0-1, any values above 1 will clip - and on the Alexa that will often be most of your image! I've seen values up to 30 in the sky on the Alexa. The same is true for 35mm footage, though you wouldn't see such crazy values as with the Alexa.

Of course it is possible to squeeze all that dynamic range into a linear file - but you lose data in the process that you might benefit from in the visual effects phase; for example with keying. I do all my keying in LOG, it just gives a better result.

No no lol I may have written it in a confusing way. We don't get any data loss on Alexa plates. No highlight clipping or anything as long as you use the LogC or cineon colorspaces. If you read in a dpx as logC you will be able to recover or stop down the viewer and see that it is there. But as soon as you try to write it back out with any other colorspace like srgb, rec709, linear, it will clip any give you magenta or grey clipped highlights. This even happens with full float 32bit exr files. I've confirmed this with Arri and the foundry. It has to do with the way the inverted log curve stays bellow 1 and then when the lit is applied it inverts back to values well above up to 16+

Oh right! Thanks for explaining it again. As I mentioned, on the last show the Alexa log footage has already been linearised and converted to exr's on ingestion, and we're rendering out exr's where the full range is retained. Nice to know about this bug though. Obviously at a certain point that gets converted to log dpx for the DI but I'm done with it by then.

So WRT the BM footage, I'm sure as compositors we would love to get the log/inverse log curves for Nuke so we have options! And not busted like the Alexa issue you speak of. But if you get a chance to try it out, let me know how you go exporting the BMD footage from Resolve Lite as exr's with Rec709/Linear Gamma and reading into Nuke. ie. do you think any magenta at the top of the range is just the sensor clipping - I would say probably, it's pretty subtle and not too objectionable. But maybe this camera has way more dynamic range than I thought and can get hotter highlights like Alexa/film, or maybe the footage was shot overexposed and just clipped. For example, if you're in "film" mode, do the zebras work in Rec709 still, or full range? etc. It seems the advice from some early adopters is to overexpose but I would still always want to protect for hilights unless that meant pushing the majority of the image into the left of the histogram to the point where it starts to deteriorate. But there does seem to be enough bits there to do this.

No no lol I may have written it in a confusing way. We don't get any data loss on Alexa plates. No highlight clipping or anything as long as you use the LogC or cineon colorspaces. If you read in a dpx as logC you will be able to recover or stop down the viewer and see that it is there. But as soon as you try to write it back out with any other colorspace like srgb, rec709, linear, it will clip any give you magenta or grey clipped highlights. This even happens with full float 32bit exr files. I've confirmed this with Arri and the foundry. It has to do with the way the inverted log curve stays bellow 1 and then when the lit is applied it inverts back to values well above up to 16+

But if you work with Alexa LogC clips in Nuke, interpreting as LogC in the Read node and rendering back as LogC, then all the dynamic range of the original is retained. I would normally recommend that pipeline, as then VFX shots go into the grade as LogC exactly like the non VFX shots. You can use an ARRI LUT as a Viewer Process in Nuke.

That is how I like to work, and I hope to be able to build a similar pipeline for the BMD camera, so it would be very useful to know what the BMDFilm transfer function is.

If you bake in a 709 or sRGB LUT when you render from Nuke, that will always clip at 1.0. I believe that is how Nuke's output LUTs are designed to behave.

ie. do you think any magenta at the top of the range is just the sensor clipping - I would say probably, it's pretty subtle and not too objectionable. But maybe this camera has way more dynamic range than I thought and can get hotter highlights like Alexa/film, or maybe the footage was shot overexposed and just clipped. For example, if you're in "film" mode, do the zebras work in Rec709 still, or full range? etc. It seems the advice from some early adopters is to overexpose but I would still always want to protect for hilights unless that meant pushing the majority of the image into the left of the histogram to the point where it starts to deteriorate. But there does seem to be enough bits there to do this.

It's not so much that you're overexposing, because that infers unrecoverable highlights. But it certainly seems to benefit from being exposed to the right whilst protecting the highlights. (which is how I expose)

I use the Zebra function, because UNLIKE most other cameras, it's representing sensor clipping irrespective of ISO, monitoring LUT (film or video) and is also linear.

100% zebra will always show sensor clipping. If you use that to make informed decisions about what to clip then you end up with an image that often appears to be overexposed. But is it if the highlights are all there ?

The camera also responds in a very linear way. I would never expose to the right like this on an Alexa, because even though the camera isn't technically overexposing at near highlights, any important detail in that exposure range will be very difficult to work with on an Alexa. It's fine if you want your highlights to be hot highlights.

This is NOT my experience with the BMCC where it seems to have a more linear response and you're more able to use the range right up to the point of clipping.

I have only seen the magenta in highlights issues in earlier versions of the camera (like the one that shot Afterglow) and earlier versions of Resolve. The recent 1.1 firmware did a lot to address the magenta in highlights issue. Perhaps it's worth testing with some more recent DNG's....

https://docs.google.com/folder/d/0B8-f- ... Y2WTQ/edit

jb

John,

Thanks for the clear explanation! That actually sounds like the ideal zebra behaviour, and indeed removes the notion of overexposing, except for the sensor limit which is what matters most. Ready to be shaped in post.

Thanks for the link to the new DNG's, I tried out this frame (one of the sunsets):
B CAM_002_2012-12-30_1924_C0002_000108.dng
I recovered float values up to around 2.3 in the exr file exported to Nuke, *assuming* that this is linear data as captured from the sensor. No magenta clipping this time although I would want to try it out with something that's saturating the sensor (I assume values of 4+).

Again, the conversion process in Resolve was to decode as clip to Rec709 and render out with linear gamma. It seems to make sense. There is then a 1:1 match when viewing in Nuke and Resolve, on my sRGB monitor, when I set Resolve's gamma back to sRGB. I would actually want to leave the clip settings at linear and do this with viewing LUTs like Nuke instead of something that gets baked in at render time so that I can grade in linear in Resolve. I haven't read the manual yet though, so I don't know how to install my own LUTs (Resolve Lite). I'm having trouble opening the downloaded pdf manual on my Mac so I'll have to pursue that later.

Another gotcha is it's not clear to me how the exposure is working in the clip decoder settings. It looks like it's working in a non-linear way compared to Nuke, where I would, say, do -2 stops in linear space. Dropping the exposure in Resolve seems to retain the highlights, where they are dimmed in Nuke. It sort of looks "better" but I think it's "wrong". Maybe the exposure adjust is happening in the BMDFilm log encoded image?

Cheers,
Michael

Again, the conversion process in Resolve was to decode as clip to Rec709 and render out with linear gamma.

Most of what you're talking about doesn't make a lot of sense to me (I'm not a post guy)

But I was interested in why you'd choose to go to REC 709 ? It doersn't really have a very wide colour gamut...especially compared to BMDFILM ?


jb

Most of what you're talking about doesn't make a lot of sense to me (I'm not a post guy)

But I was interested in why you'd choose to go to REC 709 ? It doersn't really have a very wide colour gamut...especially compared to BMDFILM ?

Maybe someone from BMD can confirm whether we are actually losing any colours in this conversion.
Right now, in Resolve Lite at least, that seems the only way to linearise the BMD-Film log image - to go to either Rec709 or P3. As you say, it's possible that there is some shrinking of the colour gamut going to Rec709, or it may just be the terminology that Resolve is using. It may just be that it's designed for viewing on a Rec709 monitor but it doesn't throw anything out. I say this is a possibility because Rec709 usually clips values above 1 yet Resolve is retaining the full dynamic range.

So because I also decoded in Resolve selecting "linear gamma" and rendered to OpenEXR which is a linear floating point format, the image is "nominally" linear within the bounds of what I know about how Resolve is working under the hood. OpenEXR is a file format that will store any colour values, including negatives values, that you want to stuff into it so it's perfectly capable of storing the linearised BMD-Film image with no loss whatsoever, dependent on how that colour space remapping is done. It's not designed as a display format, hence the image doesn't "look right" when viewed on a computer monitor - much like a Raw image -but it is linear, not log.

If there is loss, then converting to P3 would be better because it's a wider gamut but I don't have the colour space transform handy to get rid of its characteristic green cast. I would want to remap P3 to linear RGB in Nuke before I worked on it.

But ideally I would be able to export from Resolve with no loss whatsover when writing out linearised BMD-Film files as OpenEXR, and know that the image is truely linear "scene referred" as the sensor captured it, with no other characteristic applied. And/or I would want to do the log-linear conversion in Nuke, if BMD would publish the transfer function or 1D/3D LUT to go from BMD-Film to linear RGB so there is no guesswork. I notice there is some major desaturation in the BMD-Film Raw image so maybe a full 3D LUT is required to do this rather than a more basic 1D function like Cineon-to-linear, which is just remapping the black and white points and inverting the gamma.

It's all a bit of a mystery right now.

Michael-
It is a bit of mystery. Michael are you seeing values >1 in Resolve? I don't know Resolve very well either, but your experimenting has got me experimenting as well. When I bring that same frame into nuke the sun is 1,1,.999 RGB. In fact PS, Speedgrade, AE also seem to show those values.

Every .dng I open seems to be in the range of 0-1, but I don't know if that's because the dng files I have were all shot by John who used the zebra to limit the capture. Your results of 2+ recovered values seems to contradict that, unless resolve is doing something really odd that we don't understand.

-gary

Michael-
It is a bit of mystery. Michael are you seeing values >1 in Resolve? I don't know Resolve very well either, but your experimenting has got me experimenting as well. When I bring that same frame into nuke the sun is 1,1,.999 RGB. In fact PS, Speedgrade, AE also seem to show those values.

Every .dng I open seems to be in the range of 0-1, but I don't know if that's because the dng files I have were all shot by John who used the zebra to limit the capture. Your results of 2+ recovered values seems to contradict that, unless resolve is doing something really odd that we don't understand.

-gary

Hi Gary,

Yes I am getting >1 values. In the earlier sequence John uploaded with the sparklers I was getting around 4 as the max highlight value and as you mention in the sunset I was getting 2+.

When exporting as OpenEXR, I'm making sure I select full range in the render settings, and that I've switched the raw footage decode gamma to "linear". Actually, I had to redo the decode settings in the "color" room to get them to stick at render time. I've left the colour space for the decode as Rec709, although if there was sRGB or straight up "linear RGB" I would use that instead.

This gives me a linear float file with the >1 values in Nuke, and it displays the same as the Raw file does by default in Resolve, when it remaps the BMDFilm data to Rec709 for display. So, it is at least "kinda" right, as far as viewing intent and dynamic range, if not 100%.

I'd love to download and read the Resolve manual but it's not working for me right now. It downloads but it won't open.

Using J_Ops in Nuke, as I said before I think because it doesn't realise there's a log curve applied to the footage it will never display it correctly. That's part of the secret sauce. It depends on how fussy you want to be about compositing things correctly, because obviously the footage can be made to "look cool" but it is a digital cinema camera and we should be able to completely control our colour pipeline.

Overall, for the price it's great that we're getting so much more dynamic range than Canon Raw, but we need the workflow to be transparently laid out.

Michael

Here's an update on my tests getting CinemaDNG files into Nuke as "scene-referred" full linear float OpenEXR's via Resolve Lite 9.1 (I also notice that the PDF manual now opens on my Mac).

Using the ACES workflow and the CinemaDNG IDT is getting me a much nicer image than the previous method. I need to read up on ACES more, since I initially thought the ODT was a display LUT but it gets baked into the footage when I export it. So I set it to "none" meaning the footage is getting run through the IDT only, which should be saving it as linear EXR's in the ACES colour gamut. On paper this is pretty much the magic bullet because the ACES colour gamut is much wider than Rec709 and ACES is designed to work in linear floating point.

In Nuke, I loaded the custom ACES config file for OpenColorIO - you set this in the OCIO tab in Project Settings. I had to download the config file from the OpenColorIO website. I then set the viewer process to RRT(sRGB). This basically does a linear ACES to sRGB transform for my Macbook Pro monitor designed to give a pleasing final image based on the spec.

My reference here is shot 5 of Afterglow. I do know that the ACES stuff is still a work in progress and Nuke isn't using the latest OCIO ACES config file since it's not yet compiled against the most recent version of OpenColorIO. So I'm not sure how to get the colour science to match exactly. Overall the colour temperature appears the same as in Resolve but the image is slightly desaturated in comparison. It's most noticeable with the red jacket. It would be great to know how to fix this discrepancy so we have a consistent workflow.

But it's clear that this is a more accurate linearising of the image as captured by the sensor compared to the previous Rec709 method I was using. I'm finding that there are no longer any magenta hilites around the highest values, which were previously about 4 on this clip. Now they are around 10, which is getting much closer to Alexa territory. I know that these highlites aren't the result of some false gamma curve because the overall image is still pretty low contrast but it has these very high energy overbright values.

The inverse log transform applied by the IDT is showing that the BMC log curve is very close to Sony S-Log (some others have mentioned this) because I exported the same clip from Resolve Lite as BMC log and then read it into Nuke as S-Log. This yields a very similar image to the ACES linear image but with some highlight clipping on the really hot end.

So to really take advantage of what the camera has to offer, it may require using Resolve for a preprocessing step (not a bad idea at all) and dealing with ACES in Nuke but this is going to emerge over time as the default colour gamut, I would imagine.

Interested to hear from others who may have a bit more knowledge of an ACES workflow - now's the time to start reading up on it a bit more though!

Michael

Thanks for the update, Michael. I wonder if anybody has had occasion to shoot a color chart with the camera yet?

MIchael-
I got a camera so I'll be able to shoot some more controlled footage and maybe we can make sense it all.