Topics

An experiment I finally found the time to carry on: use my APS-C Samyang 16mm f/2.0 full-manual lens on my 5D3, wide open, with my favorite preset by Danne -- 3.5k 1:1 centered, 14 bit (1.6x crop).

Just an unordered sequence of clips.

Mixed results here -- some clips show the left 1/3 of the frame as out of focus / blurred. Weird. Something wrong going on with the lens? Or with the ND filters maybe? Will have to experiment more.

Thanks for wathching

WARNING (spoiler): silly question ahead.

When reviewing pics:

• On my 70D it works as always -- that is, if I press the zoom button it instantly goes to max zoom.
• On my 5D3 I think it stopped working at some point -- if I press the zoom button it just triggers the min zoom level available.

I cannot find the setting... Could you help?

Thx

Just another Dual ISO test.. hoping to attract new ML users

Another try. Shot during this warm winter holiday season.

All footage 14-bit Raw @ 3584 x 1500 / 25 fps.

As always, I appreciate (even strong) criticism, as long as it is constructive of course.

Thank you people of ML!

Sergio

Use case:

• You have a cam with ML and both CF+SD cards
• You are recording plenty of Raw footage out in the wild and have no other cards (or you do, but want to squeeze every last bit out of the cards you are using before swapping cards)
• You are using card spanning of course
• Your average write speed ratio between CF and SD does not reflect exactly the size ratio between the two (say 2x CF vs SD write speed, but 1.5x CF vs SD size)

What this 'magic function' should do:

• Calculate average write speed ratio of CF vs SD starting from size of existing MLV files found on the two cards (i.e. past write speed ratio taken as an estimate of future write speed ratios)
• Find a minimal and optimal (to be better defined of course) set of file moves (not necessarily unidirectional) between the two cards that make your final free space ratio (CF vs SD) very close to the estimated write speed ratio.

This will make sure that you end up shooting with both cards almost full, wasting no space at all.

Can this be done in lua? If so, it may even be within my reach. Or does it need to be a module?

Thx

Just love ML 

[Battle plan]

Thought I'd share my current workflow for rendering HDR10+ videos. [EDIT 7-8 apr 2022 highlighted in red] [EDIT 28 apr 2022 highlighted in blue]

Battle plan

• 
  Convert MLV to DNG (via MLV APP or any other tool capable of that)
  
• 
  Import DNG in DaVinci Resolve Studio (DVR in what follows) and grade HDR footage using an external HDR monitor (even your TV display could do the job, more on this below)
  
• 
  From DVR, export
  
  
  
  • 
    HDR10 graded footage as high-quality lossless Apple ProRes master
    
  • 
    HDR10+ metadata (JSON file) as prepared by DVR
    
• 
  Taking advantage of FastFlix (based on ffmpeg, in turn based on x265), render an H.265 Main10 HDR10 video with HDR10+ dynamic metadata built-in
  
• 
  Check for final video to embed correct HDR10 metadata (as DVR may fail in my experience): if not, correct HDR10 metadata using mkvmerge [This step should not be necessary anymore if HDR10+ analysis is performed before exporting the HDR10 Apple ProRes master video -- which is reflected in the amended detailed workflow below]
  

Requirements (apart from camera with ML of course)

• DaVinci Resolve Studio (not free)
• An external HDR monitor for grading*
• MLV APP (or any other free tool to convert MLV to Cinema DNG's)
• A recent version of ffmpeg (free)**
• FastFlix (free, available here: http://fastflix.org)
• MediaInfo (free, but not a strict requirement, just useful to check that the final result is ok)
• mkvmerge (available via mkvtoolnix**; free, may be not should be nomore necessary if DVR embeds correct HDR10 metadata, which is not always the case in my experience)

* Even though this is far from optimal (I know!), and since I am just an amateur and not a pro, to grade in HDR I use my Samsung LED TV: I got a Blackmagicdesign UltraStudio Monitor 3G to connect it to my Mac, it costs ~100 bucks. Also, to use UltraStudio Monitor 3G, make sure you have a real Thunderbolt 3 cable, not just USB. And an HDMI cable which is at least compliant with specs 2.0a.
** On my Mac, I installed it using Homebrew, which is a very convenient way to get it.

Detailed workflow

• 
  Take Raw footage (I use a 5DM3 with Danne's build, and my favorite preset currently is 3.5K 1:1 x5 @14bit)
  
• 
  In MLV APP, just load the MLV file and export as CinemaDNG
  
• 
  Load the cDNG's in DaVinci Resolve
  
• 
  Connect your external HDR monitor to your pc / Mac
  
• 
  In DVR, make sure you have the following settings (as a reference, I'm using v17.4.3: different versions may have slightly different, or even totally different options):
  
  
  
  • 
    Master Settings tab
    
    
    
    • 
      Video Monitoring section
      
      
      
      • 
        Video format: play with this till you get good output on your external monitor (if you use UltraStudio Monitor 3G, please note it is only capable of outputting HD video, so you will have to pick HD1080 here: in this case you may even want to temporarily downscale timeline resolution in DVR when working with higher resolutions, or you will end up with a cropped image being displayed on the external monitor).
        
      • 
        Video bit depth: 10 bit
        
      • 
        Enable HDR metadata over HDMI: enabled
        
  • 
    Color Management tab
    
    
    
    • 
      Color Space & Transforms section
      
      
      
      • 
        Color Science: DaVinci YRGB Color Managed
        
      • 
        Automatic color management: enabled
        
      • 
        Color processing mode: HDR
        
      • 
        Output color space: HDR PQ
        
      • 
        Display HDR on viewers if available: enabled
        
      • 
        HDR mastering is for X nits: even though this is not so clear, I think that you should enter the maximum luminosity your external monitor is capable of is expecting to be able to correctly display. For instance, I used the value I found in a technical review of my Samsung LED TV screen (550 nits: yes I know, not so good). To determine this value, personally I started from a low value of 500 nits, increased this value by steps of 100, and stopped when I noticed that my TV monitor was starting to adjust (darken) the image to accomodate higher luminosity data (this happened passing from 1000 to 1100, so I set this value @1000). If unsure, I would recommend to keep this value @1000, which is also the default suggestion made by DVR.
        
    • 
      HDR10+ section
      
      
      
      • 
        Enable HDR10+: enabled
        
• 
  In DVR Color page, grade footage to taste using your external HDR display as a reference (you will notice that same footage appears over-saturated and clipped on your pc/Mac, and that's exactly why we need external HDR displays to grade HDR footage)
  
• 
  [Anticipated this step as apparently this is necessary for correct HDR10 metadata to be embedded in the delivered ProRes master video file] When you are satisfied with the result, in DVR Color page go to Color menu > HDR10+ > Analyze All Shots. Wait till it finishes. Please note that this will enable by default the "Enable Tone Mapping Preview" checkbox in the HDR10+ tab of the Color page. You will notice that this has an effect on the footage preview as being displayed on the external HDR monitor. Not sure whether this should be enabled when grading to be honest -- but I think it should not (and indeed DVR manual says "The Enable Tone Mapping Preview checkbox lets you turn the tone mapping trim being applied off and on, so you can evaluate how the downconverted SDR version looks on your HDR display". So this checkbox seems to be relevant only for HDR-to-SDR tone mapping, i.e. I think it is trying to simulate how the result will look if you render the output video with "Tone Mapping" option enabled -- which is not an option we are interested in here. So let's leave it alone). So that's the reason why I'm suggesting to take this step after finishing grading. should you go back to grading after this step, I would suggest you disable this checkbox.
  
• 
  Then go to Deliver page, start with ProRes Master preset and then apply the following settings:
  
  
  
  • 
    Type: Apple ProRes 4444 XQ (if you have enough disk space... or else something a bit less space-consuming)
    
  • 
    Embed HDR10 Metadata: enabled
    
  • 
    Export HDR10 Metadata: enabled (this will save a .hdr10 text file that will serve at a later stage as a check that DVR really embedded the correct HDR10 metadata, even though this should be always the case now)
    
  then add to queue and render.
  
• 
  Now head to the Media page in DVR, right-click on your clip and select Timelines > Export > HDR10+ JSON: save the JSON file somewhere near your exported footage, choosing "HDR10+ Profile B Files (*.json)" from the drop-down menu [found out that this seems to produce more consistent data; also, Profile B includes more information than Profile A, in particular BezierCurveData metadata consisting of 9 Anchors and two (x,y) kneepoints]
  
• 
  We are finally done with DVR. We now have to encode our graded HDR video in H.265 format, also embedding HDR10+metadata. So we open FastFlix and
  
  
  
  • 
    make sure that rendering is set to x265 (the encoder used by ffmpeg to encode H.265 videos)
    
  • 
    load the previously rendered ProRes file
    
  • 
    feed the HDR10+ metadata JSON file ('HDR10+ Metadata' field)
    
  • 
    [moved this step up as this can be managed directly in FastFlix instead of being adjusted in a text editor] add option -profile:v main10 from the 'Profile' dropdown list, choose main10
    
  • 
    make sure that Bit Depth is set at 10-bit: yup420p10le
    
  • 
    [moved this step up as this can be managed directly in FastFlix instead of being adjusted in a text editor] if we want to fix the problem where the resulting file will not be loaded properly by QuickTime Player on Mac, we also need to add the following option in the 'Custom ffmpeg options' field: -tag:v hvc1
    
  • 
    [moved this step up as this can be managed directly in FastFlix instead of being adjusted in a text editor]I also suggest to change the output file extension to '.mov' '.mp4' instead of '.mkv', as I understand that Matroska container is not universally supported (while QuickTime MPEG-4 container has a much broader universal support base)
    
  • 
    all of the remaining options / parameters could be left untouched, however set them to taste (for instance I suggest Preset = slow, CRF = 20, and in the Audio tab you may want to convert PCM to AAC)
    
  Finally, we hit the "Convert" button and patiently wait.
  
• 
  [Bug corrected in FastFlix 4.8.0, so this workaround is nomore necessary] In FastFlix, don't click 'Add to queue' or 'Convert' buttons, as we do not want to do the encoding within FastFlix. The reason for this is that, at the time of writing, the most recent version of FastFlix (4.7.1) will force you to encode with a bit depth of 12 bit (equal to the input Apple ProRes video), and this will (for some reason) break HDR10+ compatibility. I have opened a bug report on GitHub by the way (https://github.com/cdgriffith/FastFlix/issues/311). So instead we
  
  
  
  • 
    head to "Raw Commands" tab
    
  • 
    copy the command-line command (invoking ffmpeg with a bunch of options and arguments)
    
  • 
    edit this command in favorite text editor as follows:
    
    
    
    • 
      option -pix_fmt yuv420p12le must be changed to read -pix_fmt yuv420p10le
      
• 
  [Bug corrected in FastFlix 4.8.0, so this workaround is nomore necessary] Now we take this command, paste it into Terminal / command prompt, and finally encode our HDR10+ video.
  
• 
  To check that everything went smooth, you can even inspect your final video file within MediaInfo, 'HDR format' should read SMPTE ST 2086, HDR10 compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A B compatible
  
• 
  As a final step, you need to make sure that DVR embedded the correct HDR10 metadata in the rendered video, as my experience is that sometimes for some unknown reason DVR will just embed MaxCLL = 1000 and MaxFALL = 400, that seem to be some sort of default value for DVR [turns out this happened probably because HDR10+ analysis needs to be performed before exporting HDR10 video, and not later, so this problem should not occur anymore after fixing workflow as per above]. To do this, compare these two values in your final video file (using MediaInfo) with the values you will find in the last row of the .hdr10 file that DVR exported while rendering. If the two couples of values coincide, then everything worked fine. If this is not the case, you should adjust MaxCLL and MaxFALL in your video file in order to reflect the values that are found in the .hdr10 file. One way I found to do this is the following:
  
  
  
  • 
    transcode your MPEG-4 file (or whatever container you chose) to Matroska by simply invoking ffmpeg like this: ffmpeg -i myVideo.mp4 -acodec copy -vcodec copy myVideo.mkv. Note: this is not re-encoding your video / audio, it is just changing the multimedia converter format
    
  • 
    Change your Matroska video MaxCLL and MaxFALL values like this: mkvmerge -o myVideo_correctHDR10.mkv --max-content-light 0:m --max-frame-light 0:n myVideo.mkv, where of course m and n represent respectively the values for MAXCLL and MaxFALL that you find in your .hdr10 file (last line of the file!)
    
  • 
    transcode back to MPEG-4 (or whatever container you chose above) from Matroska with ffmpeg -I myVideo_correctHDR10.mkv -acodec copy -vcodec copy -tag:v hvc1 myVideo_correctHDR10.mp4
    
  • 
    finally check again in MediaInfo and HDR10 metadata should be fine
    

Happy to receive feedbacks, comments and suggestions.

Thank you

Sergio