circuitpython/shared-module/imagecapture/ParallelImageCapture.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

45 lines
2.2 KiB
C
Raw Normal View History

ParallelImageCapture: Add continuous capture on espressif By having a pair of buffers, the capture hardware can fill one buffer while Python code (including displayio, etc) operates on the other buffer. This increases the responsiveness of camera-using code. On the Kaluga it makes the following improvements: * 320x240 viewfinder at 30fps instead of 15fps using directio * 240x240 animated gif capture at 10fps instead of 7.5fps As discussed at length on Discord, the "usual end user" code will look like this: camera = ... with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: # Do something with frame However, rather than presenting a context manager, the core code consists of three new functions to start & stop continuous capture, and to get the next frame. The reason is twofold. First, it's simply easier to implement the context manager object in pure Python. Second, for more advanced usage, the context manager may be too limiting, and it's easier to iterate on the right design in Python code. In particular, I noticed that adapting the JPEG-capturing programs to use continuous capture mode needed a change in program structure. The camera app was structured as ```python while True: if shutter button was just pressed: capture a jpeg frame else: update the viewfinder ``` However, "capture a jpeg frame" needs to (A) switch the camera settings and (B) capture into a different, larger buffer then (C) return to the earlier settings. This can't be done during continuous capture mode. So just restructuring it as follows isn't going to work: ```python with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: if shutter button was just pressed: capture a jpeg frame, without disturbing continuous capture mode else: update the viewfinder ``` The continuous mode is only implemented in the espressif port; others will throw an exception if the associated methods are invoked. It's not impossible to implement there, just not a priority, since these micros don't have enough RAM for two framebuffer copies at any resonable sizes. The capture code, including single-shot capture, now take mp_obj_t in the common-hal layer, instead of a buffer & length. This was done for the continuous capture mode because it has to identify & return to the user the proper Python object representing the original buffer. In the Espressif port, it was convenient to implement single capture in terms of a multi-capture, which is why I changed the singleshot routine's signature too.
2021-10-27 17:10:20 -04:00
/*
* This file is part of the Micro Python project, http://micropython.org/
*
* The MIT License (MIT)
*
* Copyright (c) 2019 Scott Shawcroft for Adafruit Industries
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include "shared-bindings/imagecapture/ParallelImageCapture.h"
#include "py/runtime.h"
// If the continuous-capture mode isn't supported, then this default (weak) implementation will raise exceptions for you
__attribute__((weak))
void common_hal_imagecapture_parallelimagecapture_continuous_capture_start(imagecapture_parallelimagecapture_obj_t *self, mp_obj_t buffer1, mp_obj_t buffer2) {
mp_raise_NotImplementedError(MP_ERROR_TEXT("This microcontroller does not support continuous capture."));
ParallelImageCapture: Add continuous capture on espressif By having a pair of buffers, the capture hardware can fill one buffer while Python code (including displayio, etc) operates on the other buffer. This increases the responsiveness of camera-using code. On the Kaluga it makes the following improvements: * 320x240 viewfinder at 30fps instead of 15fps using directio * 240x240 animated gif capture at 10fps instead of 7.5fps As discussed at length on Discord, the "usual end user" code will look like this: camera = ... with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: # Do something with frame However, rather than presenting a context manager, the core code consists of three new functions to start & stop continuous capture, and to get the next frame. The reason is twofold. First, it's simply easier to implement the context manager object in pure Python. Second, for more advanced usage, the context manager may be too limiting, and it's easier to iterate on the right design in Python code. In particular, I noticed that adapting the JPEG-capturing programs to use continuous capture mode needed a change in program structure. The camera app was structured as ```python while True: if shutter button was just pressed: capture a jpeg frame else: update the viewfinder ``` However, "capture a jpeg frame" needs to (A) switch the camera settings and (B) capture into a different, larger buffer then (C) return to the earlier settings. This can't be done during continuous capture mode. So just restructuring it as follows isn't going to work: ```python with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: if shutter button was just pressed: capture a jpeg frame, without disturbing continuous capture mode else: update the viewfinder ``` The continuous mode is only implemented in the espressif port; others will throw an exception if the associated methods are invoked. It's not impossible to implement there, just not a priority, since these micros don't have enough RAM for two framebuffer copies at any resonable sizes. The capture code, including single-shot capture, now take mp_obj_t in the common-hal layer, instead of a buffer & length. This was done for the continuous capture mode because it has to identify & return to the user the proper Python object representing the original buffer. In the Espressif port, it was convenient to implement single capture in terms of a multi-capture, which is why I changed the singleshot routine's signature too.
2021-10-27 17:10:20 -04:00
}
__attribute__((weak))
void common_hal_imagecapture_parallelimagecapture_continuous_capture_stop(imagecapture_parallelimagecapture_obj_t *self) {
mp_raise_NotImplementedError(MP_ERROR_TEXT("This microcontroller does not support continuous capture."));
ParallelImageCapture: Add continuous capture on espressif By having a pair of buffers, the capture hardware can fill one buffer while Python code (including displayio, etc) operates on the other buffer. This increases the responsiveness of camera-using code. On the Kaluga it makes the following improvements: * 320x240 viewfinder at 30fps instead of 15fps using directio * 240x240 animated gif capture at 10fps instead of 7.5fps As discussed at length on Discord, the "usual end user" code will look like this: camera = ... with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: # Do something with frame However, rather than presenting a context manager, the core code consists of three new functions to start & stop continuous capture, and to get the next frame. The reason is twofold. First, it's simply easier to implement the context manager object in pure Python. Second, for more advanced usage, the context manager may be too limiting, and it's easier to iterate on the right design in Python code. In particular, I noticed that adapting the JPEG-capturing programs to use continuous capture mode needed a change in program structure. The camera app was structured as ```python while True: if shutter button was just pressed: capture a jpeg frame else: update the viewfinder ``` However, "capture a jpeg frame" needs to (A) switch the camera settings and (B) capture into a different, larger buffer then (C) return to the earlier settings. This can't be done during continuous capture mode. So just restructuring it as follows isn't going to work: ```python with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: if shutter button was just pressed: capture a jpeg frame, without disturbing continuous capture mode else: update the viewfinder ``` The continuous mode is only implemented in the espressif port; others will throw an exception if the associated methods are invoked. It's not impossible to implement there, just not a priority, since these micros don't have enough RAM for two framebuffer copies at any resonable sizes. The capture code, including single-shot capture, now take mp_obj_t in the common-hal layer, instead of a buffer & length. This was done for the continuous capture mode because it has to identify & return to the user the proper Python object representing the original buffer. In the Espressif port, it was convenient to implement single capture in terms of a multi-capture, which is why I changed the singleshot routine's signature too.
2021-10-27 17:10:20 -04:00
}
__attribute__((weak))
mp_obj_t common_hal_imagecapture_parallelimagecapture_continuous_capture_get_frame(imagecapture_parallelimagecapture_obj_t *self) {
mp_raise_NotImplementedError(MP_ERROR_TEXT("This microcontroller does not support continuous capture."));
ParallelImageCapture: Add continuous capture on espressif By having a pair of buffers, the capture hardware can fill one buffer while Python code (including displayio, etc) operates on the other buffer. This increases the responsiveness of camera-using code. On the Kaluga it makes the following improvements: * 320x240 viewfinder at 30fps instead of 15fps using directio * 240x240 animated gif capture at 10fps instead of 7.5fps As discussed at length on Discord, the "usual end user" code will look like this: camera = ... with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: # Do something with frame However, rather than presenting a context manager, the core code consists of three new functions to start & stop continuous capture, and to get the next frame. The reason is twofold. First, it's simply easier to implement the context manager object in pure Python. Second, for more advanced usage, the context manager may be too limiting, and it's easier to iterate on the right design in Python code. In particular, I noticed that adapting the JPEG-capturing programs to use continuous capture mode needed a change in program structure. The camera app was structured as ```python while True: if shutter button was just pressed: capture a jpeg frame else: update the viewfinder ``` However, "capture a jpeg frame" needs to (A) switch the camera settings and (B) capture into a different, larger buffer then (C) return to the earlier settings. This can't be done during continuous capture mode. So just restructuring it as follows isn't going to work: ```python with camera.continuous_capture(buffer1, buffer2) as capture: for frame in capture: if shutter button was just pressed: capture a jpeg frame, without disturbing continuous capture mode else: update the viewfinder ``` The continuous mode is only implemented in the espressif port; others will throw an exception if the associated methods are invoked. It's not impossible to implement there, just not a priority, since these micros don't have enough RAM for two framebuffer copies at any resonable sizes. The capture code, including single-shot capture, now take mp_obj_t in the common-hal layer, instead of a buffer & length. This was done for the continuous capture mode because it has to identify & return to the user the proper Python object representing the original buffer. In the Espressif port, it was convenient to implement single capture in terms of a multi-capture, which is why I changed the singleshot routine's signature too.
2021-10-27 17:10:20 -04:00
}