For 550D, the interesting parts are:
- for video: the lossless compression
- for timelapse: the full-res LiveView
The first one was covered in detail in "the two in two out discussion", with partial success on 500D (only working outside LiveView, and output not decoded yet). Until the first issue (which wasn't present on 5D3) is solved, porting it probably doesn't make much sense, as the two models are very similar, and you'll likely run into the same problem. Newer models (60D and newer) are probably much easier to port, as their LiveView implementation is a lot closer to 5D3's.
The second one (full-res LiveView) requires adtg_gui (iso-research branch), but to explain in detail how it works, I need to try it myself on an old-gen camera, to have an idea of similarities and differences. The most promising attempts, at the time of writing, are on
700D and 5D2 (this thread).
However, increasing the resolution beyond what you get in regular LiveView requires allocating a new buffer. On recent cameras, it's easy (just enable some definitions and tell how much you need - see how it's done on 1100D and 5D3). On old generation cameras, it's hard and probably requires patching Canon code.
Other than that, it's just a matter of patching some registers (see the crop_rec source code for the various presets).
What needed now is someone with advanced knowledge of digic4 Liveview buffers
Unfortunately, my level of understanding is not there yet, but I've made some small progress emulating the LiveView in QEMU. On 500D, it appears to work for a few frames before locking up, so it's not yet published
However, both the 550D and 5D2 (and other models) now have the GUI emulation working (you can navigate Canon menu in the emulator), so the first step for LiveView is to get a set of MPU spells that covers... entering LiveView. This is easy - use the dm-spy-experiments branch (
or the startup-log builds), enter LiveView while the LED is blinking (that is, while debug messages are recorded) and then run the
extract_init_spells.py script on the log file. This alone is enough for some LiveView bitmap overlays on 500D (
Greg's screenshot - didn't try on other models). Progressing from there is much harder. I can share the current patch if there is interest, but it's "too much of a hack" at this stage. I recommend starting with easier things instead.
Currently, adtg_gui and the QEMU LV trick are low-hanging fruits. Creating debugmsg.gdb files for camera models that don't have one, or adding more entries to an existing one, is also very easy (as they mostly contain
stubs).
Porting the FRSP emulation to QEMU ranges from extremely easy to hard, depending on model. For some models, you only need to supply a reference full-res DNG and to add the camera model to the test suite - in other words, confirming it's working. Others may require some minor fiddling, others may require a deeper level of understanding. To get started, look up FRSP or FA_CaptureTestImage on the
QEMU test suite (logs, screenshots). At the time of writing, this is working on 60D, 1200D, and also 5D3 1.1.3 (where my test image has a hot pixel in the OB area, which is the reason for not passing the test). Models with GUI emulation are probably easier to adapt (just a guess, as I didn't try).
Playing with
custom logging on the dm-spy branch is also easy once you get some courage, and can be done on both a real camera or QEMU. Understanding the logs is harder. LiveView is *very* complex, so it makes sense understanding smaller bits first (such as logging task names as they are started, or following a button event).
Debugging the lossless compression routine in QEMU should also be accessible. You'll need to run both Canon's original routine and your modified one with "-d io" and compare the JPCORE and related I/O activity - see
Greg's examples.
Emulating a CR2 picture taking (until getting a valid CR2 on the SD/CF card image) should be also doable, and a whole lot easier than emulating LiveView. Maybe I should try that first.
