12-bit (and 10-bit) RAW video development discussion

Started by d, May 22, 2013, 10:58:34 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.


I'm doing some research , to understand the possibility of a 10 or 12 bit raw video found this on the  http://magiclantern.wikia.com/wiki/Register_Map
under "Image Preprocessing"
0xC0F08120 - PACK16 Control register
0xC0F08124 - PACK16_MODE (mask 0x131)
             From ProcessPathForFurikake (raw_twk):
             -------x --xx----
                  111 (0x130) = 16-bit output
                  011 (0x030) = 14-bit output
                  010 (0x020) = 14-bit output
                  001 (0x010) = 12-bit output
                  000 (0x000) = 10-bit output

So the raw_twk is just for  DIGIC 5 processor  (5D3)  or is these addresses also validate for other camera.
I wonder thou if there enough cpu power to do this or is it a matter of available ram left from ML .
Thinking out loud .  :)
Yes I think this is worth getting involved  deeper , need to do more reading 



Since d's implementation is CPU-based, the numbers are impressive when compared to memcpy, or to my C version (which is used for the previews such as in mlv_play).

Now, imagine you want to record 1920x1080 at 24 fps. What numbers would you need here?

@reddeercity: that's the register I've tweaked to reduce the bit depth. This method doesn't use the main CPU to do the processing; it calls the dedicated hardware, very similar to the method we already use for copying raw video frames for recording (edmac).

For other cameras: I think the 60D will work just by finding the right stubs; the 5D2 has the functionality, but the exact implementation looks a bit different.

No need to worry about RAM: 12-bit frames are smaller than 14-bit ones, and the conversion doesn't need any extra memory (because it's done on dedicated processing hardware - very similar to a GPU).


Man Magic Lantern keeps coming with awesome updates 10 - 12 Bits would be welcome..



NSTUB(0xFF3C1C60, ProcessPathForFurikake)

I'm assuming I need to merge raw-bit-depth and RscMgr_memory so that the patch hook will work (otherwise patch manager complains cache is locked). Unfortunately RscMgr_memory gives err 80 in LV.

on a side note: hmm...


That's right - I just pushed a few changes to the patch manager, to allow patches like this to run on 60D. I had to use a long jump, because module code is loaded at the end of RscMgr, which is far from both ML core and ROM (so regular jumps don't work).

So, for 60D at least, you need to merge patchmgr as well.

I've also got a log in QEMU showing what registers are configured (without the ResLock part):


5D3 is almost identical - except it uses different EDMAC channels.


Is this only for testing on the big cams like 5d3 and 60d, I went to get the stubs, tried it, I get smaller file sizes for the 12 and 10 bit, but there scrambled and cam goes to black and freezes after done taking picture when I do 12 and 10 bit, 14 is fine?

//** Image processing paths */
NSTUB(0xFF420AE4, ProcessPathForFurikake)
NSTUB(0xFF5EF23C, PACK16_Setup)             // PACK16_MODE:%#lx and others

not 100% there right, especially the PACK16.

Or is the problem this part that is only for 5D3?
+    /* hook to override the bit depth in PACK16 setup function */
        "PACK16: raw bit depth override"
500D/T1i  550D/T2i  600D/T3i  700D/T5i


PACK16_Setup is correct. I'm not sure what's wrong - if the output is scrambled, probably the patch override didn't work. Are there any errors in Debug menu, under Memory Patches?

I'm also working on a lower-level implementation that doesn't need any extra stubs.


500D/T1i  550D/T2i  600D/T3i  700D/T5i


Okay, it's working on 60D (if I turn off GD, then I don't get the err80), avg. time is about 117 ms (268 MB/s !).


EOSM also working, ~114 ms

NSTUB(0xff425150, ProcessPathForFurikake)
NSTUB(0xff5fa9e8, PACK16_Setup)


Got same result on 550D, no freeze, but scrambled image for 10 and 12, unless its not even suppose to work on this cam anyway, but tried anyway.
NSTUB(0xFF353274, ProcessPathForFurikake)
NSTUB(0xFF37FBE8, PACK16_Setup)

Update!!, Works on 550D, had to do a Make Clean first, Ill try on 700D now.

Works on 700D as well! Just needed a make clean.
500D/T1i  550D/T2i  600D/T3i  700D/T5i


On 700D MLV Format
14bit 820 ms 38 MiB/s
12bit 825 ms 32 MiB/s
10bit 739 ms 30 MiB/s

speed seems to jump around alot on all bits, gets faster after 2nd mlv is taken, usually by 100ms on each.

DNG Format
14bit 2970 ms 10 MiB/s
12bit 2169 ms 12 MiB/s
10bit 1960 ms 11 MiB/s

500D/T1i  550D/T2i  600D/T3i  700D/T5i


Just to clarify, I'm talking about just the speed of bit depth conversion, not the entire time it takes to save the file.


Just to check if I understand things right.

There is a dedicated chip(the digic chip?) inside the canons which can do bit depth conversion.
The test results show it can convert about 30/35 MegaByte per second.
Full HD at 24/25 fps is about 90MegaByte/s.
So the chip isn't capable of doing it fast enough for full HD video

Could be use full though for full res silent picture time lapses. You're saving some memory card space.


Read what a1ex wrote on previous page:

QuoteTiming: 120ms for a full-sized image (5936x3950).

As well as
Quote from: dmilligan on May 14, 2016, 08:36:24 PM
Okay, it's working on 60D (if I turn off GD, then I don't get the err80), avg. time is about 117 ms (268 MB/s !).

Quote from: Levas on May 15, 2016, 11:45:10 AM
Full HD at 24/25 fps is about 90MegaByte/s.
So the chip isn't capable of doing it fast enough for full HD video

Wrong, the "chip" does that already for you by providing FHD H264 files.
[size=8pt]70D.112 & 100D.101[/size]



500D :
NSTUB(0xFF327A58, PACK16_Setup)

5D2 :
NSTUB(0xFFB28D4C, PACK16_Setup)


Stubs for 5D3 1.2.3 (untested):

NSTUB(0xFF3CCC14, ProcessPathForFurikake)
NSTUB(0xFF57CA1C, PACK16_Setup)

Edit: I just Googled Furikake. Interesting, though not sure what it has to do with a camera! https://en.wikipedia.org/wiki/Furikake :)
EOS R5 1.1.0 | Canon 16-35mm f4.0L | Tamron SP 24-70mm f/2.8 Di VC USD G2 | Canon 70-200mm f2.8L IS II | Canon 100-400mm f4.5-5.6L II | Canon 800mm f5.6L | Canon 100mm f2.8L macro | Sigma 14mm f/1.8 DG HSM Art | Yongnuo YN600EX-RT II


I'm really focus about this tread.

I think, It should be so usefull to be abel to have 10 bits and 12 bits.

- For exemple : 1920x1080 60p (12 or 10bits)
Or just by recording in good quality for 30 minutes or more.
But also 3K 10bit continuously ?

So, I ask for peoples in my cathegory (mean who are noobie).

Will it be possible for everybody having a 5D mIII or 60D (...), to easily use 10 and 12 bits ? A new module will come ?

Inifnity respect to every ML scientists !


It works on old cameras. We need use the ProcessPath (without Furikake).

500D :

NSTUB(0xFF24E7F8, ProcessPath) //[DEFC]
NSTUB(0xFF327A58, PACK16_Setup)
//ProcessPath time : 96ms

We have only 3 values:
a1 = buf_in,
a2 = buf_out,
a3 = value 0 or 1 ?

So silent.c requires a small change
struct s_DefcData
    void *pSrcAddress;
    void *pDestAddr;
    uint32_t dstModeRaw;
} defc;

We can use this method on all cameras.

It might be interesting :

NSTUB(0xFF24FCCC, ProcessPath) //[SUB] DarkSubtraction
NSTUB(0xFF2506A0, ProcessPath) //[DEFD] related to TwoAdd


What are the chances of this being developed for the 7d as well?
its very exciting stuff. but i fear maybe the 7D just wont be fast enough?
7D - 3D Artist and VFX/Motion Graphics Artist



Someone tried this with the 700D?
500D 10bit and 12bit (frames after DIGIC processing) does not have a hot and cold pixels.
There is a possibility that the DIGIC also corrects focus pixels.


Yeah, I tried it on my 700D and posted results last week, but hmmmm, sounds like something I would like to test on the pixels, I didnt even think of checking the dots and pixels, just looked to see if it worked, lol.
500D/T1i  550D/T2i  600D/T3i  700D/T5i


Sorry for being impatient, is there any progress? Anything even in early stage what could be tested on 5d3?
www.pilotmovies.pl   5D Mark III, 6D, 550D