It should be simple to modify motion_detector.c to skip these pixels. We just need some way to identify where they are. Are they at the end of each row?, the beginning? split?
As long as vid_get_viewport_image_offset is implemented correctly, they are effectively at the end.
Knowing this, I could modify the code to treat things properly, or it might be better if you did, since you have a camera that can test it .
I haven't verified it, but srsa_4c's explanation seems like it is probably correct. I the dumps and live view tests I did it looked like they were mostly black, but it's possible there's some case they get set to different values.
I'll look into fixing this, afaik srsa does not have this cam.
The only case so far is when we have a width of 736 with active width of 720, I believe.
There are quite a few pre-digic 6 cameras with buffer sizes different from image size. The non THUMB_FW code uses vp_w rather than vp_bw for start and end.
The MD code should definitely NOT include buffer area that isn't part of the image.
This also gets into the discussion about buffer sizes too..which I worry we are treating inconsistently...excerpt from lib.c:
camera_screen.width = 720;
camera_screen.physical_width = camera_screen.buffer_width = 736;
camera_screen.height = camera_screen.buffer_height = 480;
camera_screen.size = 720*480;
camera_screen.buffer_size = 736*480;
is the buffer width really 736 or should it be 1472 (bytes) =736*2?
is the buffer size really 736*480? Does "buffer" mean bytes or pixels for digic 6?
Note that the camera_screen values are actually for the UI buffer, though the SX280 port happens to re-use them for viewport because they happen to be usable for that particular camera (commented "// may not be always ok" in lib.c)
The buffer width currently means pixels here. Older camera bitmap buffers were 8 bpp paletted so bytes/pixels were interchangeable.