Jump to content


  • Content Count

  • Joined

  • Last visited

About Llaasseerr

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. My "raw workflow" is just expose with a light meter, also get a grey card and then import to Resolve. In the raw settings I may use highlight reconstruction and do an exposure adjustment. Generally from there, if not working in ACES I do a CST to log (Cineon or Alexa LogC) then put the PFE lut on it to see how it will look before any log space grading. Edit: to be clear the PFE lut is the last thing in the chain but I'll put it on before grading (time-wise, not in the node graph). This gives me a nice quick one-light and should match the on-set monitor. I didn't see anything about these images that would make me deviate from that. They seem like regular raw images to me once they are in Resolve, but I'll have to see when more becomes available.
  2. Thanks for clarifying there is some kind of curve on the 8 bit image - nice to know they thought about that! I'm not sure what you mean as far as color tables in DNG (will need to give the spec another look) but I'm mainly referring to Resolve interpreting colour matrices stored as DNG metadata - which it does. So that should be the crux of the colour transform decisions it's making on the raw image. Resolve actually does the best mainstream job at interpreting a Cinema DNG image because it puts it into a high dynamic range space with no highlight clipping if you have the Resolve project set up correctly, and it exposes it more or less correctly for middle grey.
  3. I took a look at the CDNGs in Resolve just with a basic ACES setup and they both seem pretty decent - even the 8 bit one which is interesting, because an 8 bit linear image should be practically useless. Maybe it's got a log curve under the hood? That lakeside image has a lot of dynamic range variation between highlight and shadow. It might just be the right kind of image to camouflage potential issues. I'll try a non-ACES workflow where I would just interpret to Alexa LogC/AWG. From there you would write out ProRes or something. I like cinema5d, but if I understood their review correctly they seem to be saying the camera's internal picture profiles are influencing the raw recording. I don't see how that is possible, those profiles would be only baked into the h264s. They are also advocating for a log profile to interpret the raw image as well as an option for the baked h264 footage. Resolve should do a decent job of translating the DNG frames based on metadata, then if you want you can convert to your chosen log profile with CST nodes or similar. If Sigma did create a log profile and gamut, and put out a white paper then that would be nice, but I'm assuming the DNG metadata currently there isn't garbage because the images seem to look okay. A known, published log profile and gamut is essential though when recording raw for monitoring over HDMI - assuming you can add a custom LUT to your monitor. That way, you can get a decent "one light" match to what you will eventually see in Resolve after ingesting your raw footage and applying your LUT.
  4. If I disable hardware decoding of h.265 in Resolve, the image displays correctly. As @androidlad said,
  5. I've been able to fix this clamping issue in Resolve 16 Studio beta 050 on my Mac by disabling the hardware decoding for h265 in the preferences. I'm 99% sure I tried doing this months ago and it had no effect, but now it's working. Not ideal, but I was not planning to edit in h265 anyway. So I'm just punting the transcode to Resolve. I haven't done any time comparisons between rendering say ProRes out of Resolve vs a h265 to ProRes transcode in EditReady. But the advantage of doing the transcode in Resolve may be that it's part of a general ingest step where some technical luts are applied, as well as sound syncing.
  6. Glad it worked for you! Right, I'm just making sure to set the ProRes clips to Full levels when importing to Resolve. The missing image detail is most definitely back. And just to emphasise, I've done tests with both F-log and HLG, and F-log is definitely recorded at Full levels since lens cap black comes in at 95 when the transcoded ProRes is imported into Resolve at Full levels. I'm 95% sure HLG is also meant to be imported as Full levels. I mean why would they make it awkward for the user and say F-log is Full range, but HLG is video range? The HLG black level is not 0 with the lens cap, it's about 32. But that's still half of "video levels" black with HLG which is 64. That's a stop more shadow data than "video levels" black.
  7. EditReady is working for me. I transcode from h.265 to ProRes 422HQ and I'm then able to import the full data levels into Resolve.
  8. This looks like a problem I've also got on my 15" Macbook Pro 2018. It looks like the difference between the h.265 displaying at full range levels (the less contrasty version on the iMac) and video range levels (the more contrasty version on the Macbook Pro). I believe the correct one is the iMac version. I'm wondering if the reason the Macbook Pro is displaying the image incorrectly is because it's using the T2 chip to play back h.265 movies. I've found this display issue in Resolve. My workaround has been to transcode from h.265 to ProRes HQ in EditReady before importing to Resolve, and setting the imported clip data levels in Resolve to Full range. I should add the that reason I came to the conclusion the Full range (iMac) version is correct is because I did a lens cap test with F-log h.265 and the black level fell on 95/1023 which is the correct code value for black in native F-log footage according to the Fuji F-log white paper. Additionally, I've found that when software like Resolve is interpreting the h.265 as Video range, it's clipping shadow and highlight detail that is not recoverable, that is visible in the Full range version.
  9. Thanks for letting me know that you are getting consistent behaviour. I think there's some issue just on my Mac, where Resolve full range is not matching h.265 full range because when I rolled back to Resolve 15, I suddenly had the same issue where previously 15 had behaved the same as what you're saying. I have no idea what has happened on my computer because I haven't updated the system software. I've reported this to BMD but they have no idea either.
  10. I just tried turning off GPU decoding of HEVC files and the h.265 clip is now way too lifted and flat when set to Full levels. Clearly this is buggy. So doing it on the GPU yields the "correct" result, except for the clipping. Transcoding to ProRes 422HQ in EditReady seems to be the best workaround for me right now to get the full image displaying correctly in Resolve.
  11. I've tried this out in Resolve 16b3 with the same files and unlike Resolve 15, I need to set the ProRes clip to Video levels, not Full levels. Besides that, the colours now apparently match with the latest bug fixes. However I'm getting a separate luma clipping issue. Details over here in the original thread.
  12. Gotcha, the old concatenation issue. I find that Nuke is a lot more transparent about stuff like this so I don't have to dig too deep. In fact I use Nuke as a sanity check and prototype for stuff I'm trying to do in Resolve. I was reading the main X-T3 thread and I wanted to check in on this thread to say that I tested the original clips to see if the new Resolve 16 beta 3 fixed your original 601 vs 709 issue. On my machine (Macbook Pro with Vega 20 GPU) it does indeed now match the Reds in his jacket. However in 16 I now need to set the ProRes clip data levels to Video, not Full levels. This kind of makes sense considering the typical ProRes usage scenario. As long as the full dynamic range is coming in and the luma is as intended, I'm fine with that. Separately, I'm still getting an issue on my machine at least, with clipped detail in the h.265 footage straight from camera. I think this is just a v16 beta issue but I'd be interested to know if anyone else is seeing this. I've reported it to BMD. Attached are screen grabs where I graded up to clearly show the issue. The waveforms (not attached) also show the clipping. My workaround for now has been to transcode the h.265 to ProRes 422HQ using EditReady, and then in Resolve set the ProRes to Video Levels to match the h.265 at Full levels - the luma levels then match, but it's not clipped. I believe the issue may be a bug with GPU decoding of h.265 clips.
  13. Fair enough that the correction needs to go first and work on the camera original image. In which case there's no need to break up the CST operation with the HLG to linear in one node and linear to LogC in the next one. So if I'm understanding you correctly, could you just use a CST node after your matrix fix, followed by an Arri logC to Rec709 LUT then concatenate the whole thing? There is then no explicit intermediary stage there that has a floating point output outside 0-1 and your start and end points are normalized images. Having said that, you should be able to handle values outside 0-1 with a shaper LUT so as to prevent clipping. I can definitely do this in Nuke. But then is Resolve really clipping something if you generate a LUT which first goes from HLG to linear then linear to LogC, then Rec709? I haven't tried in Resolve. But going to LogC is inherently a shaper LUT.
  14. You can break it down by doing HLG to Scene Linear under the HLG LUT menu -> custom matrix fix -> Rec2100 (Rec2020) to AWG (CST node) -> Linear AWG to the Alexa 709 look (download a LUT from the Arri LUT generator). I would do a sanity check to confirm it matches without the matrix fix, then add it in. As for baking it down into a single LUT, I know I can do this in Nuke but that's an expensive piece of software so it may not be an option for everyone. Edit: corrected order of operations.
  15. Yes. That was my understanding. For sure it would be good to get a readily available fix out there for those that don't want to delve into the maths.
  • Create New...