CinemaDNG workflow for Blackmagic or Sigma FP cameras in Darktable

Software darktable
1

Hello everyone, I am embarking on a new adventure with CinemaDNG.

I’ve been looking for open source software solution to edit sequences of DNGs. At the moment it should be doable much like making a timelapse. This is once the DNGs are properly recognised by darktable.

So, the basic process is, import DNGs, edit a DNG in a sequence, make a style or apply history to a sequence, export as compressed file like PNG or JPG and then string together with ffmpeg. I will edit a corrected DNxHR video file in Shotcut. I do audio post processing in Ardour with the Harvid video tools after picture lock.

Unfortunately, no easy open open source software currently exists. However, many pieces of software can be strung together like the example above.

Just to repeat myself, as mentioned above, the DNGs from the BMPCC or BMMCC and the Sigma FP are not recognised just yet.

I’ve found Cinema DNG files and the three types of DNG are recognised properly by DCRaw.

Sigma FP examples (Not CC0) unfortunately.

Compressed 3:1 and Uncompressed BMMCC DNG sequences (NOT CC0)

The Sigma FP DNGs are 6MB each. These are 4K individual frames in a folder with a corresponding wav.

The BMMCC and BMPCC are 1080p and are 1.1MB 3:1 compressed or 2MB uncompressed. I am leaning towards getting one of these as the file sizes are much more reasonable and 1080p is fine for me. I don’t own a CinemaDNG camera yet.

There has been a little bit of interest over time in using CinemaDNG as a basis for an open source video editing app. I know that the standard is for using a log based system for editing high quality video but I actually prefer using a linear colourspace and not concerned about a somewhat more involved processing system. Also, ostensibly, CinemaDNG is an open file format and a huge amount of work has already been done in the DNG space. I think it makes for a great basis for open source high quality filmmaking.

My setup is Debian Bookworm x64 with the OBS repository for 4.6 Darktable.

My guess is there aren’t too many people working in this space but since the CinePI and others’ open source hardware resurgence as well as Elphel Apertus and others’ maybe It might become a ‘thing’?

I realise it’s not an ideal situation using darktable this way (when your only tool is a hammer everything looks like a nail), but I will be happy to use it like I have for creating timelapse sequences for the meantime.

My questions are, is there interest in a CinemaDNG workflow for any video creators here using darktable? Also, interested in any general thoughts.

2

dcraw has no bearing here, as darktable uses a project called rawspeed to decode raw files. For Canon CR3 and a few other types, it uses libraw. If your raw files are supported by either of those, they should open in dt.

Someone on here was using RawTherapee to process black magic cinema raws a while back and the results looked good to me.

Should you get some CC0 samples from any camera, please submit them to https://raw.pixls.us

3

You could also try forcing the LibRaw loading backend in darktable by adding “dng” to the list of supported extensions in the preferences.

Note that all DNGs will then be loaded using LibRaw instead of default RawSpeed.

1 Like
4

i’d be interested in processing video. vkdt has some support for loading and processing timelapse sequences, including keyframes, since the last release.

i did not succeed in loading your dng, apparently neither rawler nor rawspeed support them. probably possible to add support, but i’m no expert on this.

i’m currently not loading sidecar wav files, though that should not be difficult to do. i do load audio from magic lantern mlv video or regular mp4/compressed video.

4 Likes
5

FYI, RawSpeed tracking issue: LJpegDecompressor predictor mode 6 support · Issue #189 · darktable-org/rawspeed · GitHub

Note that recent (higher end?) DJI drones started outputting CinemaDNG as well.

3 Likes
6

i suppose the rawler issue would be this Support for cinema dng? · Issue #368 · dnglab/dnglab · GitHub but doesn’t have any development information attached to it. maybe rawspeed would be the first to crack this one here.

7

It’s sort of cracked already (it’s known lossless jpeg w/ different scatter/gather patterns), just needs implementing to RawSpeed’s coding standard… (NB: I doubt the 3:1 and 4:1 lossy modes will be prioritized.)

2 Likes
8

Is this similar to what @nongrata23 was working on?

9

workflow wise yes, the input dng here seem to use slightly different encoding though.

1 Like
10

Btw, the Blackmagic samples we have on RPU are not compliant to TIFF/EP and therefore DNG spec (for more than one model). Don’t know if Blackmagic fixed those issues in more recent firmware (please add new samples if so), otherwise interested parties should reach out to them for comment.

1 Like
11

…does your rawspeed branch open the images of the OP? didn’t get around to compiling it yet. seems to me there is some confusion wrt tile width and height (it decodes with double width and half height and then fails in rawler… other than that the predictors are already implemented).

12

It does not, it was just for messing around… Re tiles, the CFA channel scatter/gather abstraction (linked above) between the tile on TIFF container level and actual JPEG frame bytestream within needs to be implemented extra.

13

Thank you so much for looking at this. I’ve been following this for the last few days and appreciate any insight.

Really the thing is to get the CC0 samples uploaded. I still don’t own one so cannot so that myself yet.

And understood about the compression possibly not being implemented. However, if this does become a thing then the 3:1 compression of the BMMCC/BMPCC will be by far the most useful of all due to the smaller file sizes. Still 1.5GB for one minute’s 24fps 1080p compressed footage versus 3.5GB for uncompressed.

14

TBH, I wouldn’t hold my breath for this. Lossless might happen first, but this 3:1/4:1 lossy mode looks just weird (at least for the “old” RPU samples): it also uses Compression=7 w/ PhotometricInterpretation=32803 (CFA), which, according to the DNG spec, must be lossless.

On the DNG level, there seems to be no difference whatsoever between the lossless and 3:1 file (again, at least for the “old” RPU samples), and that’s just wrong - there’s no way for DNG decoders to know whether they need to deploy the lossless or lossy algorithms without actually trying to decode the streams first. This seems to be a Blackmagic custom concoction, so would need to be implemented specially…

1 Like
15

Yeah, I have yet to see any reasonable detail about BM’s implementation. The hints I’ve seen are that it’s a variation of 12-bit lossy JPEG (rare as hell on its own), there’s at least one commercial package that implements the codec but nothing open source. I don’t think libraw supports that codec. SlimRAW is the only other package I’ve seen that supports it, but it’s paid and proprietary: CinemaDNG compression modes in slimRAW - although their free trial does allow doing the first few frames of a sequence and that’s all you need to generate more format examples…

I’ve had trouble even finding decent example images. I thought we’d maybe have a solution here, but it sounds like OP is only using some of that smattering of existing examples. :frowning:

I’ve wanted to figure out the codec for a while so I can feed lossy compressed DNGs to DaVinci Resolve from a non-Blackmagic camera, but it’s hard without a camera to take experimental images with (all-black, all-white-clipped, etc)

Would not be surprised if Blackmagic has some nonstandard metadata that their software uses along with the camera model to do funky things.

16

I don’t think there’s anything special about it, seems a straight JPEG SOF1 (extended sequential DCT), just w/ 12-bit component. This is part of the JPEG spec for a while. The “variation” that was mentioned historically was actually adding the 12-bit support to libjpeg implementation AFAIK, but this is now available in libjpeg-turbo 3.0 as well OOTB.

LibRaw has no problem uncompressing this (just tried on the 3:1 RPU sample), so they must have included some special case to distinguish from lossless…

It’s all in the RawSpeed links I posted above, just that they also use JPEG SOF1 in addition to SOF3.

Perhaps this as well…

1 Like
17

Yeah I’ve been following those efforts, but when it finally hit, I was in a state of catastrophic burnout.

Might be an interesting project for later this week since I’m finally mostly recovered from chronic sleep deprivation. I’d love to compress some timelapse sequences a bit to save disk space.

18

I confirmed it is regular 12-bit JPEG, with CFA row deinterleaving. Here’s a Python snippet that let me decode a tile from an RPU sample:

import numpy as np
from imagecodecs import jpeg8_decode
# read a single tile bytestream
data = np.fromfile("BMPCC_4k_DCI_3-1.dng", dtype=np.uint8, count=1139945, offset=10240)
# encoded as deinterleaved [1088, 2064] jpeg
raw = jpeg8_decode(data).reshape([2176, 1032])

NB: You will need a fairly recent imagecodecs package that was built against libjpeg-turbo 3.x for 12-bit support.

(There might be something special re tables when encoding, but I guess you can study those from the bytestream as well.)

Note that it works exactly the same way if the codec is lossless JPEG.

2 Likes
19

At least one thing that’s unusual regarding encoding is the constant bitrate/ratio behavior, there doesn’t seem to be a way to duplicate this in libjpeg-turbo, but probably for almost any real world use case for software re-encoding, constant quality instead of constant bitrate is better, unless constant quality breaks some downstream software. CBR makes more sense for a hardware encoder that must have consistent bitrate performance.

1 Like
20

vkdt supporting cinema dng could be interesting. There is not many options in the open source domain for demoisaicking to a scene-referred image format from dng. Many people use resolve, but it comes with downsides in demoisaick quality and limited color management (it clips to rec.709 gamut and provides no options to preserve the camera native color gamut).

It looks like vkdt does open the dng files created in cinema mode on the SIGMA fp. dnglab however fails with an error complaining that it does not understand 12 bit nor 10 bit dng images.

I’ll share a few sample frames from my SIGMA fp if it helps: SIGMAfp – Google Drive

I’ve also uploaded the frames to raw.pixls.us but I’m not sure how to retrieve the link to them.