T-i-m
Posts: 47
Joined: Sun Jun 15, 2014 8:02 pm

Binned mode for sure?

Sun Jun 15, 2014 8:51 pm

Hi

I initiate my recording like this from Python with picamera with the intention of using the binned mode where 4 pixels are combined into one for better light sensitivity.

Code: Select all

camera.framerate = 8
camera.resolution = (1296, 730)
camera.meter_mode = 'backlit'
 
camera.start_recording('fileName', quality=20)
Can I then be sure it is using binned mode or is it something more I need to do? Or is there any way for me to verify that the image is a binned full sensor video?

Also, the full resolution of the sensor, I belive, is 2592×1944.
That seem to indicate to me that if I divide those numbers by two I could just as well use resolution = (1296, 972) and still get a binned mode but with a bit more area covered? Is that correct?

Many thanks!

Tim

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5946
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Binned mode for sure?

Mon Jun 16, 2014 8:36 am

There are several binned modes.
- Just 2x2 binned -> 1296x972. Will run at up to 42fps.
- 2x2 binned and then cropped to 16:9 -> 1296x730. Will run at up to 49fps.
- 2x2 binned and then line skipping too - 648x486. Will run at up to 90fps.

There is also a non-binned cropped mode that just reads out the central 1920x1080 pixels from the sensor that will run at up to 30fps.
The full 2592x1944 mode can potentially run at up to 15fps, but the rest of the infrastructure (mainly the ARM) will probably struggle at more than 10fps.

If you're asking for one of the above resolutions at a compatible framerate, then it will pick that mode. Complying with the framerate is the prime criteria of the mode selection algorithm, and then maximising the input resolution to provide the best image quality.
There's no direct way to verify the mode - sorry.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

T-i-m
Posts: 47
Joined: Sun Jun 15, 2014 8:02 pm

Re: Binned mode for sure?

Mon Jun 16, 2014 9:02 pm

Sounds good, just what I wanted!

While fiddeling with this I ran into something else that I cannot easilly verify.

It seems like the camera is not continously "re-metering" the scene while recording?
If I start recording under a certain light condition the camera adjusts as good as it can to that condition but if the lighting suddenly changes, it seems like the camera is not re-adjusting to the new condition. Is this correct?

That means if I start the camera in the early morning and just keep splitting of new files during the day it will have too bright clips at noon. But if I start and stop the camera during the day (instead of split_recording) the camera will at least adjust every time I make a new clip but then I will loose frames between the start and stop.

Regards

Tim

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5946
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Binned mode for sure?

Tue Jun 17, 2014 7:07 am

T-i-m wrote:It seems like the camera is not continously "re-metering" the scene while recording?
If I start recording under a certain light condition the camera adjusts as good as it can to that condition but if the lighting suddenly changes, it seems like the camera is not re-adjusting to the new condition. Is this correct?
No, that's not normal if you're doing video encoding (H264).
Is there a reason why you've selected the backlit metering mode in your quoted code? Is your scene genuinely backlit (ie something like a bright window in the background that you want to be ignored)? If not, then that will be confusing the algorithm as to what is meant to be ignored.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

T-i-m
Posts: 47
Joined: Sun Jun 15, 2014 8:02 pm

Re: Binned mode for sure?

Tue Jun 17, 2014 8:38 pm

Hi

Actually my scene is not typically back-lit but the important parts are in the center of the frame and I thought I read in the documentation that 'backlit' is "the same" as what on DSLR is normally refered to as "center weighted" metering. Where the light metering algorithm looks more on the middle of the frame than on the outer pixels.

Tim

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5946
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Binned mode for sure?

Wed Jun 18, 2014 10:56 am

T-i-m wrote:Actually my scene is not typically back-lit but the important parts are in the center of the frame and I thought I read in the documentation that 'backlit' is "the same" as what on DSLR is normally refered to as "center weighted" metering. Where the light metering algorithm looks more on the middle of the frame than on the outer pixels.
I'm not the expert on the AGC algo, but looking at the numbers that each mode results in, I don't see how using backlit mode would be helping.

All modes appear to be setting up two regions - a centre one, and an outer. In all cases the weightings of the two regions are the same, but they differ in the size of the centre region, backlit having the largest centre region (0.3 of the width), then average (0.25), and finally spot (0.1). There then appears to be some interesting logic to determine based on the stats from those regions to determine whether the scene is backlit or not, and alters the gain/exposure calcs accordingly. Selecting backlit alters the thresholds at which it concludes the scene is backlit.
I suspect that you selecting backlit when the scene isn't is confusing the logic and hence doesn't adapt. Average mode already has a modest amount of centre weighting anyway, so is probably just as appropriate.

As to documentation saying anything, I'm not aware of anyone with in-depth knowledge from Broadcom having defined the detail of any of the algorithm settings. Others may have made their own conclusions by experimentation, but that won't be authoritative and could be plain incorrect.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “Camera board”