DJI INSPIRE AND ZENMUSE
Short of Big Rig Custom Drones that can take an Alexa or RED Camera Package, the DJI Inspire Series is one of the most common drones that you will encounter on-set. They are small, compact, portable and fully capable of taking a high quality camera package in the form of the Zenmuse X7 or X5.
These cameras record in two professional quality formats, ProRes and CinemaDNG. As the CinemaDNG Format offers great resolution as well as the flexibility of Camera RAW it's often the preferred recording codec of many DPs. Though it's with the CinemaDNG Codec that the challenges begin to arise.
CINEMA DNG
For today's explanation I am going to use some sample footage provided by DJI. Please head over to the Download Section of the DJI Zenmuse X7 Page and download the file titled 'X7 CinemaDNG Sample File 1'.
This is a drone tracking shot of 3 Motorcyclists. It has been shot at 6K (5760x3240) in the CinemaDNG Format. The running length is 3 Secs 8 Frames at 25fps or 83 Frames Total. When you look at the footage in macOS Finder it appears as follows:
What you can see here is that CinemaDNG Files are presented as an Image Sequence. One CinemaDNG File corresponds to a single frame of footage. Image Sequences are great, they are often used in VFX Pipelines as it allows single frames to be rendered simultaneously on various different machines, a massive time saver.
When working with this DNG Image Sequence as a DIT or Data Wrangler, you not only need to transfer, verify and backup the footage but you'll also need to do a bit of Quality Control (QC). So how do you play back an image sequence to complete your QC? I recommend DaVinci Resolve, an essential tool in any Data Management Kit.
HOT TIP:
When working with any Image Sequence File Format (Zenmuse CinemaDNG / ARRIRAW from an Alexa XT) make sure you are offloading with XXHash Checksums in Shotput Pro or Silverstack.
Checksum algorithms verify every single file that is being copied. This is fine when you have 10 Quicktime Files per camera card, you only need to checksum 10 Files. But when you are working with an Image Sequence every single frame is a file, so the equivalent of those 10 Quicktime Files might be in the realm of 100,000 Image Files. Meaning you have to checksum 100,000 Files which increases offload time significantly. XXHash is the fastest checksum method and should be your go-to for image sequences. It can mean the difference between a 1 Hour Offload with XX Hash vs a 2.5 Hour Offload with MD5.
CINEMA DNG IN DAVINCI RESOLVE
Have you ever imported footage from a Zenmuse X7 or X5 and have it playback like this in DaVinci Resolve?
I certainly have. It makes you worry. Alarm bells ring raising all sorts of red flags. You think that the data is corrupt, there is an issue with the file. You double check the copied file size with Finder, yup, it matches the source footage on the camera card. You try playback directly from the camera card, it still looks corrupt. You open a single image file in Photoshop...wait, it looks fine here. What is going on?
I'll tell you what. The CinemaDNG Codec is a very GPU Intensive Codec, meaning that the ability to play it back in real-time usually depends on the grunt of your Graphics Card, both it's processor speed and it's memory. The faster your GPU the better you'll be able to playback CinemaDNG Files.
Does that mean a slow GPU can't playback CinemaDNG Files? No.
Does that means a slow GPU causes the image to look corrupt? No.
It all comes down to GPU Processing Mode. That is the cause of the problem here.
GPU PROCESSING MODE
You may have heard of terms like OpenCL, CUDA and Metal. What they refer to are APIs, software that interfaces with your computers graphics card. Think of it as a bridge between your hardware and software.
In DaVinci Resolve the default GPU Processing Mode is 'Auto'. This lets the computer pick from OpenCL, CUDA or Metal at it's whim. You will find this setting by selecting DaVinci Resolve -> Preferences -> Configuration from the Menu Bar.
Through troubleshooting and testing I have been able to determine that the Metal GPU Processing Mode is the cause of the corrupt looking images that appear when playing back Zenmuse CinemaDNG Footage in DaVinci Resolve. When Resolve is set to it's stock setting of 'Auto', it uses Apple's Metal API for certain GPUs, which causes the problem depicted above.
This problem doesn't effect all GPUs. It doesn't occur on my iMac which is running an Internal NVidia GeForce GT 755M GPU but I've had it occur on my MacBook Pro using the Internal NVidia GeForce GT 650M GPU as well as bigger rigs running a 1080Ti or a 980Ti.
So if you've got Resolve setup using its stock configuration and don't have a problem, great. If you are having an issue, thankfully the fix is easy. Simply navigate DaVinci Resolve -> Preferences -> Configuration from the Menu Bar and change the GPU Processing Mode to 'CUDA' or 'OpenCL'. You'll need to restart DaVinci Resolve for this change to come into effect.
Once the software has been restarted all of your CinemaDNG Footage from the Zenmuse Camera should work without any issue. You may just suffer laggy playback is you are using a computer with a slower GPU.
TRANSCODING
When I first encountered this issue I thought it may have just been a display problem within DaVinci Resolve. So I did a transcode of the footage to test that theory and the Graphics Issue carried over to the transcode. Super scary! This is a video of the transcoding results using the different GPU Processing Modes:
CONCLUSION
I have come across this issue many times over the years. It hadn't happened to me for a long while and just the other week when I was working with a Zenmuse X7 on an Inspire 2 the GPU Issue struck again. I did a Google to see what info I could find on this specific issue and the results were pretty much non-existent. So I decided to put together this post in hopes of helping someone else one day when they inevitably encounter this problem.
Thoughts or feedback? Let us know in the comments section below!
Till next time, I hope your data wrangling issues are far and few between.
Thanks!