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

[dmilligan]

You can compile the raw-bit-depth branch and try it with 10/12 full res silent pics.

From my quick attempt, normal silent pics don't work (and by extension, raw video) it seems b/c LV is running and these hardware modules are "busy" being utilized by Canon LV routines. Furikake just blocks until you exit LV. So to get this working for raw video it looks like we are going to need to understand more about how to manually setup these modules by overriding the low level registers that control them. That's a lot of reverse engineering work.

[a1ex]

I have a semi-functional low-level implementation (it's basically the log I've posted earlier, converted to C code), but it only converts a picture at every other attempt. If anyone is willing to debug it, I can commit it in this state.

[ItsMeLenny]

I have to make a comment to follow this, I already though I was but I wasn't

From what I've followed so far; despite going from 16bit(14) to 10 or 12 it's still not faster to write to the card?

[mk11174]

if the kind of debugging u need is possible by me, i would be glad to help out any way i can, i owe you a few favors anyway alex.

[DeafEyeJedi]

Count me in on the debugging whenever necessary @a1ex!

[a1ex]

Alright, pushed the code.

Finding the mistake might be as simple as solving one of those kid puzzles about finding the difference between two drawings (probably a typo in my code). Or - given that I couldn't figure out what was wrong in a couple of hours - it might be a little more difficult, as dmilligan already explained.

First, compile 15852ed and run "Fullres LV test" (from LiveView) to see how it should work. It will show a "full-res liveview", garbled in 12-bit and 10-bit modes (which is fine, because the drawing code expects 14-bit data).

Then, compile 21f337a and run the same test. It will do the first frame right, then it will freeze. Take the battery out.

If you add a timeout to the take_semaphore call, you will see it returning error every other frame (first correct, second bad, third correct, fourth bad and so on). Tested on 5D3 and 60D.

Note that regular full-res pictures work fine, because going to LiveView and back appears to perform the necessary cleanup (the one I've probably overlooked).

Also note that calling silent_pic_take_fullres in a loop, without going to LiveView, works fine, which puzzles me. This might help solving the mystery - turn "while(1) silent_pic_take_fullres(0)" into "silent_pic_fullres_lv_test()", step by step, and see where it fails.

To understand the code, see the log from reply #279, the Register Map wiki page, and the other links I've posted earlier for background info.

[mk11174]

On 700D, my first image is correct, second and on are garbled.

Also during 10bit, it freezes on 3rd image when I do a timeout, but continues on 12bit, but all garbled.

[a1ex]

Yeah, garbled image is what you are looking for, but without freezing.

First image is not converted to lower bit depth, that's why it looks good.

[mk11174]

Yeah, the only way I can get it to not freeze, is like you said add a timeout like this take_semaphore(edmac_write_done_sem, 100); which is what I think you meant to do, but only is stable at 12bit, 10 freezes after the 1st garbled frame passes. At 12bit, it goes fine with the correct garbled frames.

Not sure what to do with this  turn "while(1) silent_pic_take_fullres(0)" into "silent_pic_fullres_lv_test()", step by step, and see where it fails.

Don't see anything interesting I can find, but if you can think of anything for me to look at more closely and how, I will be glad to.

I was expecting to see text printed on screen, but I dont see any text at all, not sure if that is expected? I know that has nothing to do with the conversion, but I see  printf("Furikake time: %d us\n", (int)(t1 - t0));  So I assumed something would of printed?

[a1ex]

The two codes are doing pretty similar things: capture, display, convert bit depth. One is complex and works (it also saves the file, triggers overlays), the other is simple, but fails for some reason. So, to narrow down, it makes sense to simplify the complex code, step by step, to reach the simpler version, and write down at which step it fails, during the conversion process. It's very simple to do, but time-consuming.

To see the printf output, enable the debug console.

[mk11174]

Ok, printf stuff is visible now, thanks.

Wish I understood the code better, so I could know how to do the code step by step to narrow it down for you, I would take the time to do it, but honestly dont know which part is the complex one and which is the simple one, lol, most of the fuction is new, so wouldn't know where to begin and how to proceed,  sorry.

[Lucky Luke]

successing 10bit recording, it would be worth to me buying this for 100€ or even more...and I guess to manymany others on the globe.
Any movements in this area?

[Walter Schulz]

And another attempt to kill this project ...

Devs will drop out if ML goes commercial.
Donate or don't but don't expect anything to be done by throwing peanuts over the fence.

[Nutsy]

If I could afford to donate money I would... ML is a great project.

I'm on benefits (scum i know) and at the moment struggling to get by.

[Lucky Luke]

"And another attempt to kill this project ..."

Really stupid insinuation.
Just my opinion on value and possibilities of 10Bit recording.
What is wrong to became commercial if it is worth?
We are taking so much for granted...
Yes, I would pay it even more than 200€ for having no drop outs because of the card reading.
This would be a real earthquake even now late in a 4K world.
 

[dmilligan]

Can we please stay on topic and keep all discussion at a technical level. Posts like these just make it harder for those who might actually be able to contribute something to follow the conversation and find important information they need.

[MAG]

Can we please stay on topic and keep all discussion at a technical level. Posts like these just make it harder for those who might actually be able to contribute something to follow the conversation and find important information they need.

I agree.


I'm noob in code but doesn't matter. I do my best to understand and I would like to help you and try this new improvement.

Could somebody do a dropbox with the module ready to be try for 5D mark III 1.1.3 ?
Also, is it possible to chose in camera 10 and 12bit ? And can we chose resolution like when we use raw module ?

[Pierro777]

I'm new to the forum and just lurking a lot these past few days. I don't have much to contribute in terms of help (can't code etc.). But I just wanted to say you guys are all awesome. Keep up the amazing work! You help people create a lot of cool videos.

[a1ex]

On 60D, this appears to give 12-bit and 10-bit raw data for still pictures:

Code: [Select]

    MEM(0x2B308) = 0x10;   /* 12-bit */
    MEM(0x2B308) = 0;      /* 10-bit */

How did I came up with this magic value?

Look at the emulation log of the image capture process from QEMU (this post).

Code: [Select]

[PREPRO] at ShootCa:FF1C5AB8 [0xC0F08094] <- 0x30      : PACK32_MODE

This code is called from FF1C5AB8; if you look it up in the disassembled code, it's inside engio_write. There are lots of calls to this function in the firmware; to see which one is used in our case, put this into 60D/debugmsg.gdb:

Code: [Select]

b *0xFF1C5A68
commands
  silent
  print_current_location
  printf "engio_write(0x%x)\n", $r0
  c
end

Compile autoexec.bin from minimal/qemu-frsp (qemu branch), copy it onto your SD image, and run the emulation:

Code: [Select]

./run_canon_fw.sh 60D,firmware="boot=1" -s -S -d io,int -singlestep & arm-none-eabi-gdb -x 60D/debugmsg.gdb

Result:

Code: [Select]

[ShootCapture:ff084a64 ] engio_write(0x2b2fc)
[PREPRO] at ShootCa:FF1C5AB8 [0xC0F08090] <- 0x80000000: PACK32_ENB
[PREPRO] at ShootCa:FF1C5AAC [0xC0F08094] <- 0x10      : PACK32_MODE
...

Now look at 0x2b2fc in a RAM dump using a hex editor, look at these lines in the source code, and the mystery will clear up quickly.

I did not try to decode the 12-bit CR2 data, but the preview looks scrambled (as I would expect from 12-bit data interpreted as 14-bit).

It might be possible to change the bit depth of the LiveView stream with something similar.

[a1ex]

On 60D, in LiveView, this is enough to change the bit depth of the raw stream (valid values here):

Code: [Select]

EngDrvOut(0xC0F08094, bit_depth_mode);

Now, all you have to do is to remove all hardcoded references to 14 bpp and bam! you have 12-bit and 10-bit raw recording. Example code to save a 10-bit DNG: dont-click-me.c

Looking forward to your pull request

[chmee]

excellent. thumbsup!

[Danne]

 

[Walter Schulz]

Never regretted to have no popcorn in the house. Until now.

[nikfreak]

congrats for finding this @a1ex. Hopefully this won't raise Mark Free's street price in near future

[DavidSh]

wow!