Mode 1 video processing & size rounding

[jpsa]

Hello,

I'm trying to perform live processing on a video stream using mode=1 (documented as being 1920x1080 pixels from the middle of the sensor) on a camera V2.1. I'm starting with the code

Code: Select all

#!/usr/bin/env python3

import time
import picamera

class FrameHandler(object):
    def write(self, buf):
        pass

    def flush(self):
        pass

with picamera.PiCamera(sensor_mode=1, resolution='1920x1080', framerate=30) as camera:
    time.sleep(2) # let the camera warm up

    camera.start_recording(FrameHandler(), 'yuv')
    camera.wait_recording(10)
    camera.stop_recording()

which is adapted from that given in http://picamera.readthedocs.io/en/relea ... om-outputs.

When I run this code, I get the warning message

/usr/lib/python3/dist-packages/picamera/encoders.py:544: PiCameraResolutionRounded: frame size rounded up from 1920x1080 to 1920x1088
width, height, fwidth, fheight)))

Which sounds as if it will cause the image to be rescaled slightly before it's passed to my frame handler, which I don't want to happen.

How can I get un-scaled mode 1 data?

Thanks for any hints!
John

[jamesh]

It's not scaled. The ISP requires frames that are multiple of 16 in X and 32 in Y (I think that is the right way round) so 1080 is rounded up to 1088. The extra lines are added, IIRC by making the sensor area slightly larger (might be wrong there), not by scaled up the 1080.

[ethanol100]

It is the packaging of YUV values. This needs to be a multiple of 32 for height, as 1080 is not a multiple of 32 it selects next higher number 1088, you can just ignore the last 8 pixel, which will not contain valid data.

See picamera documentation:

It is also important to note that when outputting to unencoded formats, the camera rounds the requested resolution. The horizontal resolution is rounded up to the nearest multiple of 32 pixels, while the vertical resolution is rounded up to the nearest multiple of 16 pixels. For example, if the requested resolution is 100x100, the capture will actually contain 128x112 pixels worth of data, but pixels beyond 100x100 will be uninitialized.

[6by9]

It's not scaled. The ISP requires frames that are multiple of 16 in X and 32 in Y (I think that is the right way round) so 1080 is rounded up to 1088. The extra lines are added, IIRC by making the sensor area slightly larger (might be wrong there), not by scaled up the 1080.

No, wrong way around.
stride must be a multiple of 32 pixels, and buffer height a multiple of 16. 1080 is not a multiple of 16, therefore is rounded up to 1088.

In the case of mode 1 on the V2.1 sensor, exactly 1920x1080 pixels are read off the sensor.

Why are you so afraid of resizing? Under many circumstances it actually helps out in reducing noise slightly.

[jpsa]

Thank you for the replies.

I don't want to resize, as I'm keen to retain as much resolution as possible, and any resizing seems likely to introduce at least a little blurring (either that or aliasing artefacts, which would also be bad).

I may also be performance limited, so if there were any CPU cost to resizing, I'd want to avoid that too. But I think from what I've read that's done by the video processor, so probably isn't actually a concern.

It sounds as if what I need to do is exactly what I am doing, then, and just ignore the warning message.

Cheers,
John

[6by9]

I don't want to resize, as I'm keen to retain as much resolution as possible, and any resizing seems likely to introduce at least a little blurring (either that or aliasing artefacts, which would also be bad).

It's a Bayer camera, so by the time you've run it through demosaicing and similar processing steps, resize isn't going to create a huge amount of blurring.

I may also be performance limited, so if there were any CPU cost to resizing, I'd want to avoid that too. But I think from what I've read that's done by the video processor, so probably isn't actually a concern.

Correct - all done in hardware. The hardware is limited to reading or writing one pixel per clock cycle, so downscaling by large factors would limit you, but most use cases will have a very small difference (clock speed is 250MHz by default).

It sounds as if what I need to do is exactly what I am doing, then, and just ignore the warning message.

Yes, just ignore the warning, but look at "addr + (1920*1088)" for the U plane, and "addr + (1920*1088) + (1920*1088)/4" for the V plane.

[jpsa]

Actually, I only want the y plane, so that's easy
Thanks again!

[jamesh]

It's not scaled. The ISP requires frames that are multiple of 16 in X and 32 in Y (I think that is the right way round) so 1080 is rounded up to 1088. The extra lines are added, IIRC by making the sensor area slightly larger (might be wrong there), not by scaled up the 1080.

No, wrong way around.
stride must be a multiple of 32 pixels, and buffer height a multiple of 16. 1080 is not a multiple of 16, therefore is rounded up to 1088.

Doh!