Canon 80D

[a1ex]

These logs are from LiveView (10 frames each) and do not have any FA_Create/CaptureTestImage messages. No error message either. Image is still empty - make sure the last attempt is the successful one. Try in PLAY mode without any images on the card, as that mode is a lot less verbose. Please don't send more huge "empty" files - look at them with a hex editor first.

This line is interesting (that's FPS timer B):

Code: [Select]

239065: 35638.106 [CAPD] [0](0xd0006014),(0x617)

Value varies: first log has 0x4de 4 times, 0x4df 15 times. Second log has 0x616 4 times, 0x617 9 times. Assuming 27MHz and timer A = 722 (found in ROM, e.g. FF01D340), that gives 29.970 (first log) and 23.976 (second log), on average.


edit: got a hypothesis about LiveView resolution, but will only post it after being 100% certain. For that, I need two RAM dumps from LiveView, one before call("lv_save_raw", 1) and one after. Please run call("sht_mirror") before and after, too. Run the procedure in 1080p24, 1080p30, 1080p50, 1080p60, 720p50 and 720p60 (edit: x5 zoom, too - doesn't matter where it's started from).

Something like this:

Code: [Select]

dump_file("RAM4-BF.BIN", 0x40000000, 0x40000000);
call("sht_mirror"); // will create MIRROR.txt
msleep(1000);
call("lv_save_raw", 1);
msleep(1000);
dump_file("RAM4-AF.BIN", 0x40000000, 0x40000000);
call("sht_mirror"); // will append to MIRROR.txt


[goldenchild9to5]

Great job guy's..

[201400005064]

Goodluck guys! I'm new here I wish I can help. I just bought an 80d.

[sombree]

Silent photo, PLAY mode without entering live view, no images on card - link. Output file still looks like nothing.
As for the rest - you wanted me to go into movie mode and execute your example code with different resolutions/fps settings, right? If yes - link.
Code diff - I had to move log_finish() little higher - otherwise log file was empty.

[a1ex]

MIRROR.TXT: unfortunately it's mostly empty (no data). We have to either catch all debug messages, or port io_trace (ideally both).

1080p30 (just picked one):

Code: [Select]

binwalk -E -J RAM4-BF.BIN
binwalk -E -J RAM4-AF.BIN



There's a sharp peak in the "after" dump; that's likely a 14-bit raw image buffer.

Pixel peeping: graph starts at x=96px, ends at x=984px, peak starts at 638px (gimp).
File size 1072562176 => approximate address 0x2705285c +/- 0x126e20 => 0x26f00000 ... 0x2720000 (rounded).
Go there in binview and notice the pattern changing.

FE2E4B33 lv_raw_dump -> FE23BA16 get_raw_buffer -> 0x66B0 + 0x54 -> 0x67066000 -> cacheable 0x27066000.
Go there in binview to confirm the exact match. Pattern ends at about 0x27478400 (from binview)
=> size 4269056 = 0x412400 (approximate). Extract this from the RAM dump:

Code: [Select]

dd if=RAM4-AF.BIN of=raw.data bs=$((0x1000)) skip=$((0x27066)) count=$((0x413))

Let's try rawcover.py:

Code: [Select]

python rawcover.py raw.data
...
Possible RAW Bayer data found
Estimated frame width: 2480  <-- likely incorrect

Looks like a dark frame (mean=2048, mad=15, std=86; assuming high ISO; log suggests 3200).

Was the lens cap on during the experiment?! Please take it off...

[Midnight Son]

So, realistically what are the chances of getting 4k?

[jai554]

So, realistically what are the chances of getting 4k?

Should I say no chance?
https://wiki.magiclantern.fm/faq

[dfort]

Never say never and always avoid always because all generalizations are false.

Seriously, there has been some progress made on other cameras including the 700D and 5D2 that might get them closer to 4K. It seems to indicate that all these Canon DSLR's could possibly do 4k.

For the 80D it is a little too early to say because ML isn't far enough along on that camera yet.

[jai554]

Never say never and always avoid always because all generalizations are false.

Seriously, there has been some progress made on other cameras including the 700D and 5D2 that might get them closer to 4K. It seems to indicate that all these Canon DSLR's could possibly do 4k.

For the 80D it is a little too early to say because ML isn't far enough along on that camera yet.

Only in RAW recording right?

[dfort]

Right, unless someone figures out how to do mjpeg which isn't totally out of the question.

[jai554]

Right, unless someone figures out how to do mjpeg which isn't totally out of the question.

maybe if someone can figure out how to take JPEG silent pic then MJPEG will be possible
isnt it will put too much strain on the processor inside the camera?

[Walter Schulz]

Digic 4/5 based cams encode H.264/JPEG by dedicated silicon/chips and not by running some code on multi-purpose CPUs. Take it as an educated guess MJPEG is processed the same way.
"Not totally out of the question" might be added by "Do not hold your breath".

[Chellyandruu]

hey Alex,if you have any new files you want us to test on camera we are always here.just in case.

[a1ex]

Replies #275/279, in case you missed them.

The files saved by that snippet will allow finding the LiveView RAW resolution (they include the input data to save the first 14-bit DNG). I'm unable to identify resolution from a dark frame though (it would look correct at many other different resolutions), so please run that test (again) without a lens cap.

[a1ex]

Updated portable ROM dumper and would like you to run a few tests:

- color palette repeatability (including last line)
- MD5 checksums (on a 256MB filesystem)
- MD5 checksums without the cache trick (comment out disable_caches_region1_ram_d6 from reboot.c)

This dumper saves both ROM1.BIN and SFDATA.BIN (for emulation).

[sombree]

with disable_caches_region1_ram_d6():
- screen seems to be normal
- it starts dumping ROM1
- 2GB card: the after five minutes it's still dumping ROM1 - I'm not sure if camera locked up or it's that slow (probably the latter one)
- 256MB card: it dumps both ROM1 and SFDATA, but it's not that fast; last line of the text is white

without disable_caches_region1_ram_d6():
- screens looks normal, last line of the text is white
- it's much faster
- tried it three times; ROM1 and SFDATA from all three times have same checksum; I've also tried these files in QEMU and they work as expected
- for both (256MB and 2GB) cards results are the same

This is how screen looks like every time - click.

Edit: 1080p60 lv without lense cap - click.

[a1ex]

My hypothesis: the following appear to be video modes tweaked for various maximum FPS, and when you select something in Canon menu, it starts from one of these and adjusts timer B to decrease the FPS until the desired value. For example, the 60p video mode is likely based on the 63.925 FPS one. These are full raw buffer sizes, including black borders:

Code: [Select]

2096 x 676  (timer A = 722, B = 342, 109.345 FPS) @ feb47d48
2096 x 1162 (timer A = 722, B = 585, 63.925 FPS) @ ff01d1c0
2096 x 1372 (timer A = 722, B = 690, 54.197 FPS) @ ff01d250
2144 x 2402 (timer A = 722, B = 1205, 31.034 FPS) @ ff01d2e0

And these appear to be for photo mode:

Code: [Select]

6288 x 4057 (timer A = 772, B = 4061, 8.612 FPS) @ feb47c28
6288 x 4057 (timer A = 1064, B = 4061, 6.249 FPS) @ feb47cb8

Here, dcraw -i -v reports full size 6288 x 4056 (including black borders). One at 8.6 FPS, as predicted, other at 6.25 FPS. Does the 80D have some still photo mode with lower frame rate? Does that mode bring any advantages, such as lower noise?!


How I've got these numbers? Figured out registers 0xD0006008 and 0xD0006014 are the FPS timers, and D0006800/6804 are for raw resolution (DIGIC 5 uses the same registers, except they start with 0xC0F0 instead of 0xD000, and the values follow the same pattern). Scanned the ROM for known patterns (scan_raw_res.py) and got the above values.

Example:

Code: [Select]

ROM:FF01D1C0 DCD 0xD0006800
ROM:FF01D1C4 DCD 0x3000E
ROM:FF01D1C8 DCD 0xD0006804
ROM:FF01D1CC DCD 0x248021A

=> (see raw_lv_get_resolution in raw.c for interpretation) 524x581 raw => 2096x1162 (horizontal multiplier 4, vertical multiplier 2).

The multiplier setup is quite unusual. So far, all D4/5 models seem to have a hardcoded horizontal multiplier, possibly being the number of columns read out in parallel, and vertical multiplier was always 1. For 80D, multipliers are (8,1) in photo mode and (4,2) in LiveView.

63.925 fps (LiveView) vs 8.612 fps (photo):

Code: [Select]

D0006800: 0x3000E
D0006804: 0x248021A
D0006804: 2096 x 1162

D0006800: 0x3000E
D0006804: 0xFDB0320
D0006804: 6288 x 4057


Enough chit-chat; please find the first 14-bit DNG from 80D, captured at 1080p60:

000000.DNG / 000000.JPG

Camera name deliberately misspelled in EXIF, otherwise it won't open in RawTherapee (figure out why).

[OlRivrRat]

              @ Alex

       Sweet ~ & the DNG opens in IridientDeveloper Beautifully ~

[Lars Steenhoff]

works well in adobe ACR. looks good too!

[Stathman]

To early to open a bottle of champagne?   

[goldenchild9to5]

Great work Team..

[squig]

13 stops dynamic range
On sensor ADC
Dual pixel AF
80MB/s write speed

Couldn't shoot cats with it.

[emklap]

Nice progress guys :-)

80D burst speeds according to Canon's website

Approximate Speed	:	Shooting Conditions
Approx. 7 shots/sec.	:	during High-speed continuous shooting
Max. approx. 5.0 shots/sec	:	during Live View shooting or when [Servo AF] is set.
Approx. 3 shots/sec.	:	Low-speed continuous shooting Silent continuous shooting

[a1ex]

Can you find out whether different drive modes result in different values on these lines from the startup log?

Code: [Select]

  29061: 11306.683 [CAPE] E-7.2 SetSsgVSize for Readout
  29062: 11306.692 [CAPE] VSIZE(0xfdd)
  29063: 11306.705 [CAPD] [0](0xd0006008),(0x3030303)
  29064: 11306.717 [CAPD] [1](0xd000600c),(0x3030303)
  29065: 11306.728 [CAPD] [2](0xd0006010),(0x303)
  29066: 11306.739 [CAPD] [3](0xd0006014),(0xfdd)

Expected: 0x4XX instead of 0x303 in the slower drive modes.

[OlRivrRat]

   My 80D no longer wants to Play with ML. Any SD card with a BootLoader

or Rescue autoexec on it will cause the 80d to go Dark > No signs of Life.

   With "Normal" SD it works just fine.