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 1 Guest are viewing this topic.

Pierro777

Does 10bit raw mean it might be possible to have 60fps raw on the 80d someday ?!!!

Keep it up ! I wish I could help with anything lol.

hindra

SL1 100D.100A - 5D - 7D2 - 5D3 1.2.3

GutterPump

Nice find Alex ! An additional small revolution in the magical world of magic lantern.

DeafEyeJedi

Damn @a1ex, I smell the Christmas trees already...  :D
5D3.113 | 5D3.123 | EOSM.203 | 7D.203 | 70D.112 | 100D.101 | EOSM2.* | 50D.109

dmilligan

Works on 60D. Can record 10bit full resolution for about 12 seconds. 720p is about 1 minute.

https://bitbucket.org/hudson/magic-lantern/commits/9c951e497666bb4f9fc8f933fa29bec12ce16030

Not using ML greyscale preview results in about 50% of frames being corrupted

Update:
Confirmed working on EOSM, however grayscale preview is broken (all you see is the last LV frame before you hit record), only tried with crop hack

a1ex

The raw backend may be overwriting the raw_info structure and set it (or parts of it) back to 14 bits.

The easiest way is probably to block all overlays and other raw tools for other bit depths, and override the bit depth only while recording.

Supporting all bit depths in the raw backend requires a bit more work. Additionally, some features use direct pixel access (rather than using raw_get_pixel) for speed reasons; this access is probably fastest in 12-bit mode, as the packing should be a little easier (just a guess, didn't do any benchmarks).




Nice to see it working on the M; I've expecting it to work only on DIGIC 4. Here's why:

If you remember the "raw type" register (see PR #732) and look it up on the Register_Map page, the register used on DIGIC 4 models (0xC0F08114) is labeled PACK32_ISEL (probably "input selection"). The bit depth register is 0xC0F08094 PACK32_MODE, so they must be related somehow. On 5D3, this register is 0xC0F37014, so I've expected the ISEL register to be moved as well. Didn't try yet.

Side note: PACK16 and PACK32 are probably image processing modules that write data from the image processor to the main RAM (the RAM visible from the ARM processor) and can convert it to various bit depths (hence the name "pack"). In a similar way, DSUNPACK, ADUNPACK and UNPACK24 are used to read image data from the ARM processor (which can be packed at various bit depths) and bring it somehow to other image processing modules. In all cases, the MODE register for each of these modules is used to configure the bit depth.

It isn't clear how to connect those processing modules together, but it's probably done with the ISEL switches (whose exact meaning is largely unknown, other than the above assumption about their naming).

rbrune

Quote from: dmilligan on November 03, 2016, 02:47:08 AM
Confirmed working on EOSM, however grayscale preview is broken (all you see is the last LV frame before you hit record), only tried with crop hack

If I remember correctly the grayscale preview was always broken on the M - or did that work at one point?
Regardless, this sounds like I really need to figure out a way to increase the frame size for raw recording on the M now.

myown

WOW!! You do such a great work!! Congratulations and many, many many thanks!

I have a 60D and wanne test this  :)
Do i have to consider something special?



a1ex

Quote from: dmilligan on November 03, 2016, 02:47:08 AM
Not using ML greyscale preview results in about 50% of frames being corrupted

Figured it out - when getting the raw stream into main memory, we have to adjust frame size. On models that use CONFIG_EDMAC_RAW_SLURP (see http://builds.magiclantern.fm/features.html ), this parameter is under our control. On other models, this configuration is done in Canon code, which probably must be patched somehow.

Also, confirmed it working on 5D3.

To get clean image, you will have to change raw_info.bits_per_pixel from the raw recording module (this is not yet committed).

For more details, see the commit messages from this branch:
https://bitbucket.org/hudson/magic-lantern/commits/branch/raw_video_10bit_12bit

nikfreak

So what's more difficult? Switching all cams to use raw slurp in combination with running RAW_DEBUG_TYPE for all of 'em or better patching Canon code somehow. Already successfully used hardcoded values for slurp a while ago on 70D but the preferred raw type didn't match and I didn't feel like having time to try to find the best value for it at that time. Would other cameras still need hardcoded values for all modes when using raw slurp or do you have an idea to find / read them "magically" somehow...
[size=8pt]70D.112 & 100D.101[/size]

a1ex

Enabling the new method on all models is desirable IMO, because we will have a single way of doing things. However, each model is likely to have its own quirks, so it's a bit of work.

Patching the ROM is probably easier, but pretty ugly if you ask me. You had problems with it on 70D (PR #734), but I don't know where to begin debugging it. Maybe just merging the latest patchmgr could work, who knows.

BTW, for 70D, trying different raw types might reveal other streams, such as the dual pixel sub-images (just a guess, no idea how it's done on 5D4, but I wouldn't be surprised if Canon implemented it that way).

dmilligan


goldenchild9to5

@a1lex Great job.. that's just awesome smaller file sizes and longer recording times amazing.  This feature will be soo.. useful for the new gen canon's using 1080p 60fps 

ItsMeLenny

What's the state of the 550D in getting 10bit and 12bit.
(We all know the 550D is the most important camera of them all :P)

dmilligan


araucaria

QuoteAudionut:
Is the code just truncating bits, or is it compressing them into the remaining?

edit:  The OP states that the bits are being compressed.

Curious to know what kind of compression it is. Great work, I'm very excited.

ch_d

Let me know if you need a 5DM2 (+VAF Filter) tester ...
5D MII

andy kh

5D Mark III - 70D

ilia3101

Tested it on a 5D2, almost works, 10 bit works on every other frame, the rest are pink, and 12 bit also works on every other frame with the rest being completely pink. I have uploaded some DNG files made with MLP. I tried in full sensor resolution and 16:9, full sensor made 12 bit completely pink, but I only tested that once. Here are the 10 and 12 bit DNG files including 14 bit for comparison: https://drive.google.com/file/d/0BwvDlbhZgsGGY1BUM2tyN0YwdVk/view?usp=sharing The boring shot of a map is not enough to judge quality, but I think 10 and 12 bit look the good as 14 bit in this case.

"Disclaimer": I don't know if I missed anything, or did anything wrong, is there anything else to enable other than raw_rec module?

ch_d

What do you mean by "works on every other frame"?
5D MII

dmilligan

Quote from: Ilia3101 on November 04, 2016, 07:28:25 PM
Tested it on a 5D2, almost works, 10 bit works on every other frame, the rest are pink, and 12 bit also works on every other frame with the rest being completely pink.
This will be the case on all cameras except 5d3, 60D, and 600D, unless you set preview mode to ML grayscale. And you may notice the preview just looks like garbage once you start recording (ML grayscale preview can't handle anything but 14bit data yet)

ilia3101

I mean this: first frame is fine, no corruption or pink artifacts, the next is all pink and corrupted, no image, then another fine one, another corrupted... and this cycle continues, so only half of the frames are not ruined, and when played back(which MlRawViewer refused to do), it just flashes pink every other frame.

Edit: @dmilligan just saw your post, thanks for clarifying, I will test again.

reddeercity

Goods news here , I'm glad to see this thread back active.
I would like to test this on my 5D2 please ,  @Ilia3101 could I try your module ?
I don't have a environment to comply ml right now , just pm me  or post it here
:) 

ilia3101

@reddeercity Uploaded the module: https://drive.google.com/file/d/0BwvDlbhZgsGGbHBxeVpBTXJ4Zlk/view?usp=sharing, maybe you'll have some more success than I did.
After some more testing with ML grayscale, I have concluded that it does't yet fully work with the 5D mark ii, whatever I try, there's always something going wrong every other frame in 10 bit, either a pink frame or the bottom half is of another frame, and 12 bit seems to have weird colourful static all the time :'(.

reddeercity

@lia3101 , thanks I'll do some testing and post the results  ;D