The resolution section covers registers that seem to be related to width and height (possibly by some scaling factor). They are pretty much guesswork (tweaked them until they happened to work), but there are hints that not all of them might be needed. However, the exact meaning of these registers is still unknown (possibly configuring resolution for various image processing modules in the compression path).
Before, I've got these register values from QEMU, but the procedure is not very straightforward (it can emulate only a part of the lossless compression process). Now you can get the full conversation with the hardware, by using
io_trace. Some of the registers (but maybe not all) are also present in the regular logs.
Look up the above registers in the photo capture log - you'll find the values from the comments.
Capture similar logs for other camera models (possibly with different sensor resolutions) to identify which registers might have to be changed.
I have some (incomplete) logs from QEMU with register diffs, but with the current tools (which evolved a lot during last year), I think it's best to capture them from real hardware using the latest io_trace_full branch. If it crashes, try reducing the logged range (to capture only the registers we are actually interested in).
Recommended models for comparison:
- 5D3 vs 6D vs 70D (all of them using ProcessTwoInTwoOutLosslessPath)
- all other D5 models (using ProcessTwoInTwoOutJpegPath)
- all other D4 models (caveat: io_trace is more likely to crash)
To get these logs in QEMU, the basic procedure is to call the compression routine with fake data. It won't get emulated completely anyway, so you can just plug some random address (0x12345678 will do), and give valid width and height to the raw_info structure passed to lossless_compress_raw. You don't have to capture any image. The test code can be executed from silent.c's init function, for example:
static unsigned int silent_init()
{
/* keep the old stuff */
/* code for running only in QEMU - no error checking done, no valid input, no valid results expected */
struct memSuite * out_suite = shoot_malloc_suite_contig(16 * 1024 * 1024);
struct raw_info out_raw_info = {
.buffer = 0x12345678,
.width = 1920,
.height = 1080,
};
lossless_compress_raw(&out_raw_info, out_suite);
return 0;
}
Then, run with -d io:
# from platform/CAM.FW
make install_qemu ML_MODULES=silent
# from qemu-eos
./run_canon_fw.sh CAM,firmware="boot=1" -d debugmsg,io [...]
The emulation will fail at the semaphore, but you will see the registers set by the lossless compression routine (and you can compare them with the ones obtained from io_trace). If they are identical, that's a very good sign.
TODO: automate this task, run it in QEMU for all single-DIGIC models that have lossless routines identified, then diff all these logs. Difficulty: easy, just time-consuming (edit: done for DIGIC 5, took only 2 hours; I've expected it would take a lot more).
lossless-1080-qemu-5D3.loglossless-1080-qemu-6D.loglossless-1080-qemu-70D.loglossless-1080-qemu-700D.loglossless-1080-qemu-650D.loglossless-1080-qemu-EOSM.loglossless-1080-qemu-100D.loglossless-1080-qemu-EOSM2.loglossless-1080-qemu-5D3-vs-6D.htmllossless-1080-qemu-5D3-vs-70D.htmllossless-1080-qemu-6D-vs-70D.htmllossless-1080-qemu-5D3-vs-700D.htmllossless-1080-qemu-700D-vs-650D.htmllossless-1080-qemu-700D-vs-EOSM.htmllossless-1080-qemu-700D-vs-100D.htmllossless-1080-qemu-100D-vs-EOSM2.htmlIn particular, the differences between 700D (working) and 650D (having artifacts) are quite small. No idea what they are, but... try overriding the highlighted registers and see if it helps.
The differences between 700D and EOSM (both working) are not relevant (one is some clock enabled for some unknown device, the other is from a malloc'ed address). The differences between 700D and 100D look a little more interesting, but they are probably related to how powersaving is implemented in hardware (TLDR: not relevant). The 100D and EOSM2 are also nearly identical (as expected).
For 70D, registers 0xC0F37300 and 0xC0F373E8 seem to be resolution-related, but are not used on 5D3/6D; @esas - please try. The subsequent registers smell like some possible Bayer configuration...
Emulating the full photo capture can be also useful, as it will use the unaltered Canon configuration, but it's a lot harder (it's much easier to get this one with io_trace).
One bit of mystery: on 5D3, capturing a still photo from movie mode's LiveView breaks the lossless compressor from mlv_lite. Investigating this one could give even more clues for figuring out what happens on the other models.
Why are they different on the two cameras? IDK.
You have pasted the answer a few lines above that
