Pixel counting:
- video frame: 1736x976
- CR2 full size: 5280x3528
- best guess: some image processing modules are configured for width=5280, but receive width=1736 as input
- let's render a gradient image like that:
octave:1> x = 1:5280; y = 1:3528;
octave:2> [x,y] = meshgrid(x,y);
octave:3> g = x+y;
octave:4> imwrite(g / max(g(:)), 'gradient.png');
octave:5> h = reshape(g'(1:1736*976), [1736 976])';
octave:6> imwrite(h / max(h(:)), 'wrong-width.png');
# the reverse transformation would be:
# r = reshape(h'(1:5280*320), [5280 320])';
A better match can be obtained with x = 1:5280/2 (reason: Canon code reads the image in
two half-width slices, while ML reconfigures them as full width). So, a better hypothesis would be: Canon's image processing hardware is configured for width=2640, but receives input with width=1736.
=> start reading
here for a possible solution (possibly fixable just by tinkering with the code until it works).
In particular, either look at the differences between 650D and 700D (though none of them refer to registers related to image width, but might enable some additional processing that depends on image size), or try adjusting the width registers, as done on 5D3 and 6D (search for A4F in the logs, as 0xA4F+1 = 2640).
What I'm wondering: what kind of processing is done by the lossless encoder, that depends on image width?! (besides the encoding itself, which is not supposed to change the image content in any way)
Also wondering: what lossless compression rates are you getting on 700D, EOSM and 100D? Do they depend on horizontal resolution? (a bit off-topic, but pretty sure dfort is reading). I'd expect bad compression rates if the declared width does not match the actual image width (but that won't affect decoding).
