Magic Lantern springs back with to their feet to knock Blackmagic on its ass!
The Magic Lantern Development team is back with some very good news, they now think 14bit Raw VIDEO recordings will be possible at practical runtimes! Here is what A1ex had to say;
"Heh, people got excited without even knowing the big news: g3gg0 just discovered how to use the DMA cropping routines, which just made possible RAW video recording at 1920x1080 at 24fps on 1000x cards. Technical: we now know how to copy a cropped version of some [of the] image buffer at very high speeds (over 700MB/s), and with this trick we can save the video data [to] the card at full speed, without being slowed down by image borders, for example. [14bit] 1920x1080 RAW video now requires 83MB/s at 24fps, so it should work just fine on 1000x cards. I didn't try it."
There you have it, the Canon 5D mark III is now a Cinema Camera!
Could it be, is it possible that this $2,500, 5lb "soccer-mom tool" can now do everything an $80,000, 15lb "movie-making machine" can do? Probably not but for $77,500 cheaper it's close enough, but that's not really a fair comparison, since the 5D3 was never designed to be up against a proper Cinema Camera.
Some may argue the 5D3 even with 24fps 1080p 14bit raw is not suitable for cinema work, especially Blackmagic Cinema Camera owners, so let's take a look into the 5D3's inner and outer workings to gauge just how well (or poorly) it stacks up against the big boys and if it's worthy to be counted among them.
First lets look into the 5D3's sensor; a 5760 x 3840 pixel, 36 x 24mm 14-bit 640EI CMOS imaging sensor with 11.7 stops of dynamic range and a clean image at ISO 2293. Comparing that to the Blackmagic Cinema Camera which has a 2532 x 1366 pixel, 15.6 x 8.8mm 16-bit 800EI CMOS sensor with a claimed 13 stops of Dynamic Range (squeezed into a 12bit file). What we can see from these specs is that the physical pixels (photodiodes) of the 5D3 and the BmCC are very similar in size, which would mean similarly clean ISO and Dynamic Range.
Some may argue the 5D3 even with 24fps 1080p 14bit raw is not suitable for cinema work, especially Blackmagic Cinema Camera owners, so let's take a look into the 5D3's inner and outer workings to gauge just how well (or poorly) it stacks up against the big boys and if it's worthy to be counted among them.
First lets look into the 5D3's sensor; a 5760 x 3840 pixel, 36 x 24mm 14-bit 640EI CMOS imaging sensor with 11.7 stops of dynamic range and a clean image at ISO 2293. Comparing that to the Blackmagic Cinema Camera which has a 2532 x 1366 pixel, 15.6 x 8.8mm 16-bit 800EI CMOS sensor with a claimed 13 stops of Dynamic Range (squeezed into a 12bit file). What we can see from these specs is that the physical pixels (photodiodes) of the 5D3 and the BmCC are very similar in size, which would mean similarly clean ISO and Dynamic Range.
Dynamic Range
The Blackmagic BmCC is pulling in 13 stops of Dynamic Range versus the 5D3's almost 12 stops; to be clear that means the BmCC can capture a little over double the shades of color than the 5D3 can. The BmCC fills up its 12bit image files to its maximum capacity of 13 stops (if counting clipped whites as a stop) while the 5D3 stores it's 12 stops in a bloated 14 bit file. In the end they are not that far off from each other, especially if you plan to edit in a 10bit codec like ProRes or an 8bit one like AVC. So the BmCC has an advantage of about a stop (twice the information) in dynamic range which appears to be mostly in the highlights.
Image Noise
Arri Alexa: 3392x2200 pixels, 28x18mm, 800EI, 14bit CMOS sensor with 14 stops of dynamic range.
Canon C500:
Sony F65:
RED Epic:
RED Scarlet: 5120x2700 pixels
Sony FS700:
Canon 1Dc:
Blackmagic Cinema Camera:
Cinema Image Acquisition Solution! Not only is the image raw but its from a properly scaled down sensor as the 5Dmk3 uses 3x3 pixel binning rather then line skipping to minimize aliasing artifacts, very similar to the procedure used in proper Cinema cameras.
Here is what G3gg0 just posted:
...this code is EXPERIMENTAL. It will cause [m]any random failures that lead from data loss to crashing cameras.
As you know, ML is very stable, but sometimes code at this early stage causes unforseen problems.
Prepare yourself for that before you go shooting. (a backup CF card, ML-free SD card)
Key ingredients:
- canon has an internal buffer that contains the RAW data
-This is what they found first, it is the data from the sensor scan for video
- we understand the high speed DMA controller "EDMAC" a lot better now and know how to crop areas out of an image
-They were using the "video pipeline" to try to get the RAW data out first but now are using the "RAW photo pipeline"
- we know how to get the maximum rate out of the CF card and so achieve to get up to 90MiB/s
-They were writing the files frame by frame (small chunks) before but now writing them together as big blocks of data
- we provided a reference tool that converts the Magic Lantern .RAW movie into single .DNG frames plus a MJPEG script
-Converts to DNG or MJPEG in computer
All together sums up to the most advanced 14-bit RAW recording system people can get for less than 3 kEUR.
We will prepare a full article as soon we see this code being stable enough for public testing.
And A1ex has added:
Heh, people got excited without even knowing the big news: g3gg0 just discovered how to use the DMA cropping routines, which just made possible RAW video recording at 1920x1080 at 24fps on 1000x cards.
Technical: we now know how to copy a cropped version of some image buffer at very high speeds (over 700MB/s), and with this trick we can save the video data the card at full speed, without being slowed down by image borders, for example.
1920x1080 RAW video now requires 83MB/s at 24fps, so it should work just fine on 1000x cards. I didn't try it.
So, I've lost my patience and rewritten the lv_rec module from scratch, to use these new routines and to experiment with different buffering algorithms. The new module is called raw_rec and outputs the same file format (RAW files).
Main changes:
- The ring buffer only uses 32MB memory blocks (maximum we can get). Reason: card benchmarks showed higher data rates for large buffers.
- Frame copying is done outside the LiveView task (not sure if it has any effect).
- When the buffer gets full, it skips some frames, rather than stopping.
- Fewer hardcoded things: should be easier to port.
- Resolution presets, from 640x320 to 3592x1320.
Just like lv_rec, this is in very early stages, so you have to compile it yourself.
If you try it, I'd like you to look for any signs of image tearing. The source raw data is single-buffered, but it's possible to make it double-buffered if the vertical sync is less than ideal.
All credits go to g3gg0 - without his reverse engineering work on understanding the image processor, this would have been impossible.
Example video:
https://vimeo.com/66153520
