General notes[]
There are a couple of different sections containing different kinds of images (different resolution, encoding, ...). All addresses below are in the "0x40000000" range, but they seem to be the same in the 0x2, 0x3, 0x6, 0x7 range. That is, a similar image as in 0x44000080 can be found at, eg. 0x34000080. The 0x1 and 0x5 range, on the other hand, seem to contain constantly changing garbage when read out[?].
Discovered sections[]
Sections with YUV422 data that are always present[]
The following adresses were found when examining dumps when the camera was in aperture-priority mode, with live view enabled. They seem to be unchanged when changing modes (eg going to movie mode, ...). Some of them *do* however seem to change when actually starting to record, but there seems to be some occasional inconsistencies. [Maybe these are somehow allocated/assigned dynamically or so, and we should hunt for the appropriate pointers in some Canon structures?]
0x44000080 / 0x46000080[]
- resolution: 928x616
- pitch: 1856
- odd.png from img.py: http://i.imgur.com/WROse.png
- when recording this becomes [UNSURE!]:
- rec @ 1080p -> 1576x1048 OR 1576x630 (have had both of them in different dumps ... OR ...(?)), pitch 3152
- rec @ 720p -> 1576x630, pitch 3152
- rec @ 480p -> 720x480, pitch 1440
0x4FCB6C00[]
- resolution: 720x624
- pitch: 1440
- odd.png from img.py: http://i.imgur.com/4JQJM.png
- this one seems to work to get zebra.c going
0x41B07800 / 0x43738800 / 0x43B48800[]
- resolution: 720x424
- pitch: 1440
- odd.png from img.py: http://i.imgur.com/EoSS4.png
Sections with YUV422 data that are only present when recording[]
The following adresses are a bit flaky and certainly incomplete. These were tested only while recording at 1080p. They can change location and resoution with different modes. Note that I couldn't always reproduce thim in the memory dumps (the camera hung after duping, having to reset by removing the battery every time). I stopped bothering with finding them as I don't see a use for them yet. If you need these buffers for a feature, you can try searching for them yourself, or ask me and I'll fiddle with it some more --RoalFre <roald [dot] frederickx [at] gmail [dot] com>.
0x4d02800[]
- resolution: 1280x732
- pitch: 2560
- when recording at 1080p
- note: at the top there are 4 extra duplicates of the "first" line of pixels and bottom rows of pixels are 8 duplicated lines, see odd.png from img.py: http://i.imgur.com/lkMHd.png
- chopping off those 12 duplicate lines gives you a 1280x720 image starting at at 0x4D0780
0x48000080[]
- resolution: 1576x1048
- pitch: 3152
- when recoding at 1080p
Sections with different encoding[]
0x43F51000 / 0x4FD97C00 / 0x4FE1B000[]
- resolution: 630x624
- pitch: 630
- full.png from img.py: http://i.imgur.com/SgZ0c.png
- note that this buffer contains several images stacked "side by side" (see the image above)
- also note that the image is heavily posterized
0x43FD6420[]
- resolution: 320x240
- pitch: 320
- full.png from img.py: http://i.imgur.com/arQyU.png
- note that the endianness seems to be reversed!