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

[reddeercity]

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"

Code: [Select]

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 outputSo 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 

[a1ex]

@markodarko:

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).

[goldenchild9to5]

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

[dmilligan]

60D:

Code: [Select]

NSTUB(0xFF3C1C60, ProcessPathForFurikake)
NSTUB(0xFF3FC6FC, PACK16_Setup)

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...

[a1ex]

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):

furikake-60d.log

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

[mk11174]

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?

Code: [Select]

//** Image processing paths */
NSTUB(0xFF420AE4, ProcessPathForFurikake)
NSTUB(0xFF5EF23C, PACK16_Setup)             // PACK16_MODE:%#lx and othersnot 100% there right, especially the PACK16.





Or is the problem this part that is only for 5D3?

Code: [Select]

+    /* hook to override the bit depth in PACK16 setup function */
    patch_hook_function(
        (uintptr_t)&PACK16_Setup,
        0xE92D4010,
        PACK16_Setup_hook,
        "PACK16: raw bit depth override"
    );

[a1ex]

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.

[mk11174]

Nope, it just says None.

[dmilligan]

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 !).

[dmilligan]

EOSM also working, ~114 ms

Code: [Select]

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


[mk11174]

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.

Code: [Select]

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.

[mk11174]

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

[dmilligan]

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

[Levas]

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.
 

[nikfreak]

Read what a1ex wrote on previous page:

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

As well as

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 !).

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.

[Levas]

Ah, so this is a big discovery

[Greg]

500D :

Code: [Select]

NSTUB(0xFF327A58, PACK16_Setup)
5D2 :

Code: [Select]

NSTUB(0xFFB28D4C, PACK16_Setup)

[chris_overseas]

Stubs for 5D3 1.2.3 (untested):

Code: [Select]

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

[MAG]

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 !

[Greg]

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

500D :

Code: [Select]

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

We have only 3 values:

Code: [Select]

a1 = buf_in,
a2 = buf_out,
a3 = value 0 or 1 ?
So silent.c requires a small change

Code: [Select]

struct s_DefcData
{
    void *pSrcAddress;
    void *pDestAddr;
    uint32_t dstModeRaw;
} defc;
We can use this method on all cameras.


It might be interesting :

Code: [Select]

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


[Nutsy]

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?

[ddelreal]

What would this do for the 550D?

[Greg]

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.

[mk11174]

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.

[kgv5]

Sorry for being impatient, is there any progress? Anything even in early stage what could be tested on 5d3?