@KnarfB: thanks for your analysis
- pi camera uses yuv420 (ref: https://picamera.readthedocs.io/en/rele ... yuv-format
- with this chroma subsampling the block would be 16*16 (ref: https://en.wikipedia.org/wiki/JPEG#Block_splitting
- the height (1944) is not divisible by 16, so the pipeline needs to either pad the bottom or crop the image
no problem up to this point, but 2592 is divisible by 16 - it doesn't require cropping.
extrapolating from the summary above, we conclude that the pipeline crops instead of pads.
- from 1944 vertical, only 1936 are retained
- although the horizontal side is not cropped, the image is stretched while maintaining 4:3 ratio
- 1936 * 4 /3 = 2581.33 horizontal - rounded down to 2581
- the 2581*1936 is stretched to 2592*1944, filling in the gap of 11*8
on 2nd thought, there's an argument against "JPEG compresses MCUs" as the culprit.
using modified raspicam, the output of video port (from video_buffer_callback) is used.
by tapping at this point, the image shouldn't be compressed yet.
however the output from raspicam resembles the output of raspivid.
unless there's another insight, seems like still port is the way to go.
a bit oot:
- strobe works in all resolutions with raspiraw (ril.rawcam with the still port)
- strobe works in vga & 1280*960 resolution but not in 5mp resolution with raspicam (ril.camera with the video port)
- - - the frex registers would be reset/ignored.