[libcamera-devel,v4,16/16] py: examples: Add simple-cam.py

16123 diff mbox series

Add a Python version of simple-cam from:

https://git.libcamera.org/libcamera/simple-cam.git

Let's keep this in the libcamera repository until the Python API has
stabilized a bit more, and then we could move this to the simple-cam
repo.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 src/py/examples/simple-cam.py | 350 ++++++++++++++++++++++++++++++++++
 1 file changed, 350 insertions(+)
 create mode 100755 src/py/examples/simple-cam.py

Hi Tomi

On Mon, May 30, 2022 at 05:27:22PM +0300, Tomi Valkeinen wrote:
> Add a Python version of simple-cam from:
>
> https://git.libcamera.org/libcamera/simple-cam.git
>
> Let's keep this in the libcamera repository until the Python API has
> stabilized a bit more, and then we could move this to the simple-cam
> repo.
>

Looks very nice and it could indeed be added to the simple-cam
repository (or should we create an example directory in libcamera
sources ?)

Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>

Thanks
  j

> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>  src/py/examples/simple-cam.py | 350 ++++++++++++++++++++++++++++++++++
>  1 file changed, 350 insertions(+)
>  create mode 100755 src/py/examples/simple-cam.py
>
> diff --git a/src/py/examples/simple-cam.py b/src/py/examples/simple-cam.py
> new file mode 100755
> index 00000000..2b81bb65
> --- /dev/null
> +++ b/src/py/examples/simple-cam.py
> @@ -0,0 +1,350 @@
> +#!/usr/bin/env python3
> +
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright (C) 2022, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> +
> +# A simple libcamera capture example
> +#
> +# This is a python version of simple-cam from:
> +# https://git.libcamera.org/libcamera/simple-cam.git
> +#
> +# \todo Move to simple-cam repository when the Python API has stabilized more
> +
> +import libcamera as libcam
> +import selectors
> +import sys
> +import time
> +
> +TIMEOUT_SEC = 3
> +
> +
> +def handle_camera_event(cm):
> +    # cm.get_ready_requests() will not block here, as we know there is an event
> +    # to read.
> +
> +    reqs = cm.get_ready_requests()
> +
> +    # Process the captured frames
> +
> +    for req in reqs:
> +        process_request(req)
> +
> +
> +def process_request(request):
> +    global camera
> +
> +    print()
> +
> +    print(f'Request completed: {request}')
> +
> +    # When a request has completed, it is populated with a metadata control
> +    # list that allows an application to determine various properties of
> +    # the completed request. This can include the timestamp of the Sensor
> +    # capture, or its gain and exposure values, or properties from the IPA
> +    # such as the state of the 3A algorithms.
> +    #
> +    # To examine each request, print all the metadata for inspection. A custom
> +    # application can parse each of these items and process them according to
> +    # its needs.
> +
> +    requestMetadata = request.metadata
> +    for id, value in requestMetadata.items():
> +        print(f'\t{id.name} = {value}')
> +
> +    # Each buffer has its own FrameMetadata to describe its state, or the
> +    # usage of each buffer. While in our simple capture we only provide one
> +    # buffer per request, a request can have a buffer for each stream that
> +    # is established when configuring the camera.
> +    #
> +    # This allows a viewfinder and a still image to be processed at the
> +    # same time, or to allow obtaining the RAW capture buffer from the
> +    # sensor along with the image as processed by the ISP.
> +
> +    buffers = request.buffers
> +    for _, buffer in buffers.items():
> +        metadata = buffer.metadata
> +
> +        # Print some information about the buffer which has completed.
> +        print(f' seq: {metadata.sequence:06} timestamp: {metadata.timestamp} bytesused: ' +
> +              '/'.join([str(p.bytes_used) for p in metadata.planes]))
> +
> +        # Image data can be accessed here, but the FrameBuffer
> +        # must be mapped by the application
> +
> +    # Re-queue the Request to the camera.
> +    request.reuse()
> +    camera.queue_request(request)
> +
> +
> +# ----------------------------------------------------------------------------
> +# Camera Naming.
> +#
> +# Applications are responsible for deciding how to name cameras, and present
> +# that information to the users. Every camera has a unique identifier, though
> +# this string is not designed to be friendly for a human reader.
> +#
> +# To support human consumable names, libcamera provides camera properties
> +# that allow an application to determine a naming scheme based on its needs.
> +#
> +# In this example, we focus on the location property, but also detail the
> +# model string for external cameras, as this is more likely to be visible
> +# information to the user of an externally connected device.
> +#
> +# The unique camera ID is appended for informative purposes.
> +#
> +def camera_name(camera):
> +    props = camera.properties
> +    location = props.get(libcam.properties.Location, None)
> +
> +    if location == libcam.properties.LocationEnum.Front:
> +        name = 'Internal front camera'
> +    elif location == libcam.properties.LocationEnum.Back:
> +        name = 'Internal back camera'
> +    elif location == libcam.properties.LocationEnum.External:
> +        name = 'External camera'
> +        if libcam.properties.Model in props:
> +            name += f' "{props[libcam.properties.Model]}"'
> +    else:
> +        name = 'Undefined location'
> +
> +    name += f' ({camera.id})'
> +
> +    return name
> +
> +
> +def main():
> +    global camera
> +
> +    # --------------------------------------------------------------------
> +    # Get the Camera Manager.
> +    #
> +    # The Camera Manager is responsible for enumerating all the Camera
> +    # in the system, by associating Pipeline Handlers with media entities
> +    # registered in the system.
> +    #
> +    # The CameraManager provides a list of available Cameras that
> +    # applications can operate on.
> +    #
> +    # There can only be a single CameraManager within any process space.
> +
> +    cm = libcam.CameraManager.singleton()
> +
> +    # Just as a test, generate names of the Cameras registered in the
> +    # system, and list them.
> +
> +    for camera in cm.cameras:
> +        print(f' - {camera_name(camera)}')
> +
> +    # --------------------------------------------------------------------
> +    # Camera
> +    #
> +    # Camera are entities created by pipeline handlers, inspecting the
> +    # entities registered in the system and reported to applications
> +    # by the CameraManager.
> +    #
> +    # In general terms, a Camera corresponds to a single image source
> +    # available in the system, such as an image sensor.
> +    #
> +    # Application lock usage of Camera by 'acquiring' them.
> +    # Once done with it, application shall similarly 'release' the Camera.
> +    #
> +    # As an example, use the first available camera in the system after
> +    # making sure that at least one camera is available.
> +    #
> +    # Cameras can be obtained by their ID or their index, to demonstrate
> +    # this, the following code gets the ID of the first camera; then gets
> +    # the camera associated with that ID (which is of course the same as
> +    # cm.cameras[0]).
> +
> +    if not cm.cameras:
> +        print('No cameras were identified on the system.')
> +        return -1
> +
> +    camera_id = cm.cameras[0].id
> +    camera = cm.get(camera_id)
> +    camera.acquire()
> +
> +    # --------------------------------------------------------------------
> +    # Stream
> +    #
> +    # Each Camera supports a variable number of Stream. A Stream is
> +    # produced by processing data produced by an image source, usually
> +    # by an ISP.
> +    #
> +    #   +-------------------------------------------------------+
> +    #   | Camera                                                |
> +    #   |                +-----------+                          |
> +    #   | +--------+     |           |------> [  Main output  ] |
> +    #   | | Image  |     |           |                          |
> +    #   | |        |---->|    ISP    |------> [   Viewfinder  ] |
> +    #   | | Source |     |           |                          |
> +    #   | +--------+     |           |------> [ Still Capture ] |
> +    #   |                +-----------+                          |
> +    #   +-------------------------------------------------------+
> +    #
> +    # The number and capabilities of the Stream in a Camera are
> +    # a platform dependent property, and it's the pipeline handler
> +    # implementation that has the responsibility of correctly
> +    # report them.
> +
> +    # --------------------------------------------------------------------
> +    # Camera Configuration.
> +    #
> +    # Camera configuration is tricky! It boils down to assign resources
> +    # of the system (such as DMA engines, scalers, format converters) to
> +    # the different image streams an application has requested.
> +    #
> +    # Depending on the system characteristics, some combinations of
> +    # sizes, formats and stream usages might or might not be possible.
> +    #
> +    # A Camera produces a CameraConfigration based on a set of intended
> +    # roles for each Stream the application requires.
> +
> +    config = camera.generate_configuration([libcam.StreamRole.Viewfinder])
> +
> +    # The CameraConfiguration contains a StreamConfiguration instance
> +    # for each StreamRole requested by the application, provided
> +    # the Camera can support all of them.
> +    #
> +    # Each StreamConfiguration has default size and format, assigned
> +    # by the Camera depending on the Role the application has requested.
> +
> +    stream_config = config.at(0)
> +    print(f'Default viewfinder configuration is: {stream_config}')
> +
> +    # Each StreamConfiguration parameter which is part of a
> +    # CameraConfiguration can be independently modified by the
> +    # application.
> +    #
> +    # In order to validate the modified parameter, the CameraConfiguration
> +    # should be validated -before- the CameraConfiguration gets applied
> +    # to the Camera.
> +    #
> +    # The CameraConfiguration validation process adjusts each
> +    # StreamConfiguration to a valid value.
> +
> +    # Validating a CameraConfiguration -before- applying it will adjust it
> +    # to a valid configuration which is as close as possible to the one
> +    # requested.
> +
> +    config.validate()
> +    print(f'Validated viewfinder configuration is: {stream_config}')
> +
> +    # Once we have a validated configuration, we can apply it to the
> +    # Camera.
> +
> +    camera.configure(config)
> +
> +    # --------------------------------------------------------------------
> +    # Buffer Allocation
> +    #
> +    # Now that a camera has been configured, it knows all about its
> +    # Streams sizes and formats. The captured images need to be stored in
> +    # framebuffers which can either be provided by the application to the
> +    # library, or allocated in the Camera and exposed to the application
> +    # by libcamera.
> +    #
> +    # An application may decide to allocate framebuffers from elsewhere,
> +    # for example in memory allocated by the display driver that will
> +    # render the captured frames. The application will provide them to
> +    # libcamera by constructing FrameBuffer instances to capture images
> +    # directly into.
> +    #
> +    # Alternatively libcamera can help the application by exporting
> +    # buffers allocated in the Camera using a FrameBufferAllocator
> +    # instance and referencing a configured Camera to determine the
> +    # appropriate buffer size and types to create.
> +
> +    allocator = libcam.FrameBufferAllocator(camera)
> +
> +    for cfg in config:
> +        ret = allocator.allocate(cfg.stream)
> +        if ret < 0:
> +            print('Can\'t allocate buffers')
> +            return -1
> +
> +        allocated = len(allocator.buffers(cfg.stream))
> +        print(f'Allocated {allocated} buffers for stream')
> +
> +    # --------------------------------------------------------------------
> +    # Frame Capture
> +    #
> +    # libcamera frames capture model is based on the 'Request' concept.
> +    # For each frame a Request has to be queued to the Camera.
> +    #
> +    # A Request refers to (at least one) Stream for which a Buffer that
> +    # will be filled with image data shall be added to the Request.
> +    #
> +    # A Request is associated with a list of Controls, which are tunable
> +    # parameters (similar to v4l2_controls) that have to be applied to
> +    # the image.
> +    #
> +    # Once a request completes, all its buffers will contain image data
> +    # that applications can access and for each of them a list of metadata
> +    # properties that reports the capture parameters applied to the image.
> +
> +    stream = stream_config.stream
> +    buffers = allocator.buffers(stream)
> +    requests = []
> +    for i in range(len(buffers)):
> +        request = camera.create_request()
> +        if not request:
> +            print('Can\'t create request')
> +            return -1
> +
> +        buffer = buffers[i]
> +        ret = request.add_buffer(stream, buffer)
> +        if ret < 0:
> +            print('Can\'t set buffer for request')
> +            return -1
> +
> +        # Controls can be added to a request on a per frame basis.
> +        request.set_control(libcam.controls.Brightness, 0.5)
> +
> +        requests.append(request)
> +
> +    # --------------------------------------------------------------------
> +    # Start Capture
> +    #
> +    # In order to capture frames the Camera has to be started and
> +    # Request queued to it. Enough Request to fill the Camera pipeline
> +    # depth have to be queued before the Camera start delivering frames.
> +    #
> +    # When a Request has been completed, it will be added to a list in the
> +    # CameraManager and an event will be raised using eventfd.
> +    #
> +    # The list of completed Requests can be retrieved with
> +    # CameraManager.get_ready_requests(), which will also clear the list in the
> +    # CameraManager.
> +    #
> +    # The eventfd can be retrieved from CameraManager.event_fd, and the fd can
> +    # be waited upon using e.g. Python's selectors.
> +
> +    camera.start()
> +    for request in requests:
> +        camera.queue_request(request)
> +
> +    sel = selectors.DefaultSelector()
> +    sel.register(cm.event_fd, selectors.EVENT_READ, lambda fd: handle_camera_event(cm))
> +
> +    start_time = time.time()
> +
> +    while time.time() - start_time < TIMEOUT_SEC:
> +        events = sel.select()
> +        for key, mask in events:
> +            key.data(key.fileobj)
> +
> +    # --------------------------------------------------------------------
> +    # Clean Up
> +    #
> +    # Stop the Camera, release resources and stop the CameraManager.
> +    # libcamera has now released all resources it owned.
> +
> +    camera.stop()
> +    camera.release()
> +
> +    return 0
> +
> +
> +if __name__ == '__main__':
> +    sys.exit(main())
> --
> 2.34.1
>

On 05/06/2022 15:46, Jacopo Mondi wrote:
> Hi Tomi
> 
> On Mon, May 30, 2022 at 05:27:22PM +0300, Tomi Valkeinen wrote:
>> Add a Python version of simple-cam from:
>>
>> https://git.libcamera.org/libcamera/simple-cam.git
>>
>> Let's keep this in the libcamera repository until the Python API has
>> stabilized a bit more, and then we could move this to the simple-cam
>> repo.
>>
> 
> Looks very nice and it could indeed be added to the simple-cam
> repository (or should we create an example directory in libcamera
> sources ?)

I think examples in libcamera repository makes sense. Why was the 
simple-cam added to a separate repository originally?

  Tomi

Hi Tomi,

On Mon, Jun 06, 2022 at 12:00:16PM +0300, Tomi Valkeinen wrote:
> On 05/06/2022 15:46, Jacopo Mondi wrote:
> > Hi Tomi
> >
> > On Mon, May 30, 2022 at 05:27:22PM +0300, Tomi Valkeinen wrote:
> > > Add a Python version of simple-cam from:
> > >
> > > https://git.libcamera.org/libcamera/simple-cam.git
> > >
> > > Let's keep this in the libcamera repository until the Python API has
> > > stabilized a bit more, and then we could move this to the simple-cam
> > > repo.
> > >
> >
> > Looks very nice and it could indeed be added to the simple-cam
> > repository (or should we create an example directory in libcamera
> > sources ?)
>
> I think examples in libcamera repository makes sense. Why was the simple-cam
> added to a separate repository originally?
>

I don't recall we had any discussion. Simple-cam started as a
live-coded example for a conference talk, than it has been made a
"real" application later by Kieran, but I don't remember if we had
discussions about where to keep it.

Probably we considered cam and qcam more useful examples ?
One other thing is that if we keep simple-cam in libcamera repository,
it will have to be updated when the API change, which is good as we
know it will be up to date, but is one more thing to maintain on the
other hand...

>  Tomi

On Mon, Jun 06, 2022 at 11:11:16AM +0200, Jacopo Mondi wrote:
> On Mon, Jun 06, 2022 at 12:00:16PM +0300, Tomi Valkeinen wrote:
> > On 05/06/2022 15:46, Jacopo Mondi wrote:
> > > On Mon, May 30, 2022 at 05:27:22PM +0300, Tomi Valkeinen wrote:
> > > > Add a Python version of simple-cam from:
> > > >
> > > > https://git.libcamera.org/libcamera/simple-cam.git
> > > >
> > > > Let's keep this in the libcamera repository until the Python API has
> > > > stabilized a bit more, and then we could move this to the simple-cam
> > > > repo.
> > >
> > > Looks very nice and it could indeed be added to the simple-cam
> > > repository (or should we create an example directory in libcamera
> > > sources ?)
> >
> > I think examples in libcamera repository makes sense. Why was the simple-cam
> > added to a separate repository originally?
> 
> I don't recall we had any discussion. Simple-cam started as a
> live-coded example for a conference talk, than it has been made a
> "real" application later by Kieran, but I don't remember if we had
> discussions about where to keep it.
> 
> Probably we considered cam and qcam more useful examples ?
> One other thing is that if we keep simple-cam in libcamera repository,
> it will have to be updated when the API change, which is good as we
> know it will be up to date, but is one more thing to maintain on the
> other hand...

One of the reasons we've kept it in a separate repository was to
showcase the build system for a standalone libcamera application. That's
less of a concern for a Python application.

Hi Tomi,

Thank you for the patch.

On Mon, May 30, 2022 at 05:27:22PM +0300, Tomi Valkeinen wrote:
> Add a Python version of simple-cam from:
> 
> https://git.libcamera.org/libcamera/simple-cam.git
> 
> Let's keep this in the libcamera repository until the Python API has
> stabilized a bit more, and then we could move this to the simple-cam
> repo.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>  src/py/examples/simple-cam.py | 350 ++++++++++++++++++++++++++++++++++
>  1 file changed, 350 insertions(+)
>  create mode 100755 src/py/examples/simple-cam.py
> 
> diff --git a/src/py/examples/simple-cam.py b/src/py/examples/simple-cam.py
> new file mode 100755
> index 00000000..2b81bb65
> --- /dev/null
> +++ b/src/py/examples/simple-cam.py
> @@ -0,0 +1,350 @@
> +#!/usr/bin/env python3
> +
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright (C) 2022, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> +
> +# A simple libcamera capture example
> +#
> +# This is a python version of simple-cam from:
> +# https://git.libcamera.org/libcamera/simple-cam.git
> +#
> +# \todo Move to simple-cam repository when the Python API has stabilized more
> +
> +import libcamera as libcam
> +import selectors
> +import sys
> +import time
> +
> +TIMEOUT_SEC = 3
> +
> +
> +def handle_camera_event(cm):
> +    # cm.get_ready_requests() will not block here, as we know there is an event
> +    # to read.
> +
> +    reqs = cm.get_ready_requests()
> +
> +    # Process the captured frames
> +
> +    for req in reqs:
> +        process_request(req)

This got me to think a bit more about event handling. libcamera will
expose other events (such as frame start, error events, ...). What would
you think of replacing get_ready_requests() with a handle_events()
function that would take a set of callbacks for different types of
events ? Or we could add handle_request, handle_sof, ... properties to
CameraManager, to store the event handlers, which would still be called
by handle_events().

> +
> +
> +def process_request(request):
> +    global camera
> +
> +    print()
> +
> +    print(f'Request completed: {request}')
> +
> +    # When a request has completed, it is populated with a metadata control
> +    # list that allows an application to determine various properties of
> +    # the completed request. This can include the timestamp of the Sensor
> +    # capture, or its gain and exposure values, or properties from the IPA
> +    # such as the state of the 3A algorithms.
> +    #
> +    # To examine each request, print all the metadata for inspection. A custom
> +    # application can parse each of these items and process them according to
> +    # its needs.
> +
> +    requestMetadata = request.metadata
> +    for id, value in requestMetadata.items():
> +        print(f'\t{id.name} = {value}')
> +
> +    # Each buffer has its own FrameMetadata to describe its state, or the
> +    # usage of each buffer. While in our simple capture we only provide one
> +    # buffer per request, a request can have a buffer for each stream that
> +    # is established when configuring the camera.
> +    #
> +    # This allows a viewfinder and a still image to be processed at the
> +    # same time, or to allow obtaining the RAW capture buffer from the
> +    # sensor along with the image as processed by the ISP.
> +
> +    buffers = request.buffers
> +    for _, buffer in buffers.items():
> +        metadata = buffer.metadata
> +
> +        # Print some information about the buffer which has completed.
> +        print(f' seq: {metadata.sequence:06} timestamp: {metadata.timestamp} bytesused: ' +
> +              '/'.join([str(p.bytes_used) for p in metadata.planes]))
> +
> +        # Image data can be accessed here, but the FrameBuffer
> +        # must be mapped by the application
> +
> +    # Re-queue the Request to the camera.
> +    request.reuse()
> +    camera.queue_request(request)
> +
> +
> +# ----------------------------------------------------------------------------
> +# Camera Naming.
> +#
> +# Applications are responsible for deciding how to name cameras, and present
> +# that information to the users. Every camera has a unique identifier, though
> +# this string is not designed to be friendly for a human reader.
> +#
> +# To support human consumable names, libcamera provides camera properties
> +# that allow an application to determine a naming scheme based on its needs.
> +#
> +# In this example, we focus on the location property, but also detail the
> +# model string for external cameras, as this is more likely to be visible
> +# information to the user of an externally connected device.
> +#
> +# The unique camera ID is appended for informative purposes.
> +#
> +def camera_name(camera):
> +    props = camera.properties
> +    location = props.get(libcam.properties.Location, None)
> +
> +    if location == libcam.properties.LocationEnum.Front:
> +        name = 'Internal front camera'
> +    elif location == libcam.properties.LocationEnum.Back:
> +        name = 'Internal back camera'
> +    elif location == libcam.properties.LocationEnum.External:
> +        name = 'External camera'
> +        if libcam.properties.Model in props:
> +            name += f' "{props[libcam.properties.Model]}"'
> +    else:
> +        name = 'Undefined location'
> +
> +    name += f' ({camera.id})'
> +
> +    return name
> +
> +
> +def main():
> +    global camera
> +
> +    # --------------------------------------------------------------------
> +    # Get the Camera Manager.
> +    #
> +    # The Camera Manager is responsible for enumerating all the Camera
> +    # in the system, by associating Pipeline Handlers with media entities
> +    # registered in the system.
> +    #
> +    # The CameraManager provides a list of available Cameras that
> +    # applications can operate on.
> +    #
> +    # There can only be a single CameraManager within any process space.
> +
> +    cm = libcam.CameraManager.singleton()
> +
> +    # Just as a test, generate names of the Cameras registered in the
> +    # system, and list them.
> +
> +    for camera in cm.cameras:
> +        print(f' - {camera_name(camera)}')
> +
> +    # --------------------------------------------------------------------
> +    # Camera
> +    #
> +    # Camera are entities created by pipeline handlers, inspecting the
> +    # entities registered in the system and reported to applications
> +    # by the CameraManager.
> +    #
> +    # In general terms, a Camera corresponds to a single image source
> +    # available in the system, such as an image sensor.
> +    #
> +    # Application lock usage of Camera by 'acquiring' them.
> +    # Once done with it, application shall similarly 'release' the Camera.
> +    #
> +    # As an example, use the first available camera in the system after
> +    # making sure that at least one camera is available.
> +    #
> +    # Cameras can be obtained by their ID or their index, to demonstrate
> +    # this, the following code gets the ID of the first camera; then gets
> +    # the camera associated with that ID (which is of course the same as
> +    # cm.cameras[0]).
> +
> +    if not cm.cameras:
> +        print('No cameras were identified on the system.')
> +        return -1
> +
> +    camera_id = cm.cameras[0].id
> +    camera = cm.get(camera_id)
> +    camera.acquire()
> +
> +    # --------------------------------------------------------------------
> +    # Stream
> +    #
> +    # Each Camera supports a variable number of Stream. A Stream is
> +    # produced by processing data produced by an image source, usually
> +    # by an ISP.
> +    #
> +    #   +-------------------------------------------------------+
> +    #   | Camera                                                |
> +    #   |                +-----------+                          |
> +    #   | +--------+     |           |------> [  Main output  ] |
> +    #   | | Image  |     |           |                          |
> +    #   | |        |---->|    ISP    |------> [   Viewfinder  ] |
> +    #   | | Source |     |           |                          |
> +    #   | +--------+     |           |------> [ Still Capture ] |
> +    #   |                +-----------+                          |
> +    #   +-------------------------------------------------------+
> +    #
> +    # The number and capabilities of the Stream in a Camera are
> +    # a platform dependent property, and it's the pipeline handler
> +    # implementation that has the responsibility of correctly
> +    # report them.
> +
> +    # --------------------------------------------------------------------
> +    # Camera Configuration.
> +    #
> +    # Camera configuration is tricky! It boils down to assign resources
> +    # of the system (such as DMA engines, scalers, format converters) to
> +    # the different image streams an application has requested.
> +    #
> +    # Depending on the system characteristics, some combinations of
> +    # sizes, formats and stream usages might or might not be possible.
> +    #
> +    # A Camera produces a CameraConfigration based on a set of intended
> +    # roles for each Stream the application requires.
> +
> +    config = camera.generate_configuration([libcam.StreamRole.Viewfinder])
> +
> +    # The CameraConfiguration contains a StreamConfiguration instance
> +    # for each StreamRole requested by the application, provided
> +    # the Camera can support all of them.
> +    #
> +    # Each StreamConfiguration has default size and format, assigned
> +    # by the Camera depending on the Role the application has requested.
> +
> +    stream_config = config.at(0)
> +    print(f'Default viewfinder configuration is: {stream_config}')
> +
> +    # Each StreamConfiguration parameter which is part of a
> +    # CameraConfiguration can be independently modified by the
> +    # application.
> +    #
> +    # In order to validate the modified parameter, the CameraConfiguration
> +    # should be validated -before- the CameraConfiguration gets applied
> +    # to the Camera.
> +    #
> +    # The CameraConfiguration validation process adjusts each
> +    # StreamConfiguration to a valid value.
> +
> +    # Validating a CameraConfiguration -before- applying it will adjust it
> +    # to a valid configuration which is as close as possible to the one
> +    # requested.
> +
> +    config.validate()
> +    print(f'Validated viewfinder configuration is: {stream_config}')
> +
> +    # Once we have a validated configuration, we can apply it to the
> +    # Camera.
> +
> +    camera.configure(config)
> +
> +    # --------------------------------------------------------------------
> +    # Buffer Allocation
> +    #
> +    # Now that a camera has been configured, it knows all about its
> +    # Streams sizes and formats. The captured images need to be stored in
> +    # framebuffers which can either be provided by the application to the
> +    # library, or allocated in the Camera and exposed to the application
> +    # by libcamera.
> +    #
> +    # An application may decide to allocate framebuffers from elsewhere,
> +    # for example in memory allocated by the display driver that will
> +    # render the captured frames. The application will provide them to
> +    # libcamera by constructing FrameBuffer instances to capture images
> +    # directly into.
> +    #
> +    # Alternatively libcamera can help the application by exporting
> +    # buffers allocated in the Camera using a FrameBufferAllocator
> +    # instance and referencing a configured Camera to determine the
> +    # appropriate buffer size and types to create.
> +
> +    allocator = libcam.FrameBufferAllocator(camera)
> +
> +    for cfg in config:
> +        ret = allocator.allocate(cfg.stream)
> +        if ret < 0:
> +            print('Can\'t allocate buffers')
> +            return -1
> +
> +        allocated = len(allocator.buffers(cfg.stream))
> +        print(f'Allocated {allocated} buffers for stream')
> +
> +    # --------------------------------------------------------------------
> +    # Frame Capture
> +    #
> +    # libcamera frames capture model is based on the 'Request' concept.
> +    # For each frame a Request has to be queued to the Camera.
> +    #
> +    # A Request refers to (at least one) Stream for which a Buffer that
> +    # will be filled with image data shall be added to the Request.
> +    #
> +    # A Request is associated with a list of Controls, which are tunable
> +    # parameters (similar to v4l2_controls) that have to be applied to
> +    # the image.
> +    #
> +    # Once a request completes, all its buffers will contain image data
> +    # that applications can access and for each of them a list of metadata
> +    # properties that reports the capture parameters applied to the image.
> +
> +    stream = stream_config.stream
> +    buffers = allocator.buffers(stream)
> +    requests = []
> +    for i in range(len(buffers)):
> +        request = camera.create_request()
> +        if not request:
> +            print('Can\'t create request')
> +            return -1
> +
> +        buffer = buffers[i]
> +        ret = request.add_buffer(stream, buffer)
> +        if ret < 0:
> +            print('Can\'t set buffer for request')
> +            return -1
> +
> +        # Controls can be added to a request on a per frame basis.
> +        request.set_control(libcam.controls.Brightness, 0.5)
> +
> +        requests.append(request)
> +
> +    # --------------------------------------------------------------------
> +    # Start Capture
> +    #
> +    # In order to capture frames the Camera has to be started and
> +    # Request queued to it. Enough Request to fill the Camera pipeline
> +    # depth have to be queued before the Camera start delivering frames.
> +    #
> +    # When a Request has been completed, it will be added to a list in the
> +    # CameraManager and an event will be raised using eventfd.
> +    #
> +    # The list of completed Requests can be retrieved with
> +    # CameraManager.get_ready_requests(), which will also clear the list in the
> +    # CameraManager.
> +    #
> +    # The eventfd can be retrieved from CameraManager.event_fd, and the fd can

I know you renamed this from fd to event_fd recently, but I'm thinking
about going back to fd. The rationale is that it needs to be an fd on
which the application can select(), but the fact that it's an event_fd
is an implementation detail.

These comments are not to be addressed in this patch, so

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> +    # be waited upon using e.g. Python's selectors.
> +
> +    camera.start()
> +    for request in requests:
> +        camera.queue_request(request)
> +
> +    sel = selectors.DefaultSelector()
> +    sel.register(cm.event_fd, selectors.EVENT_READ, lambda fd: handle_camera_event(cm))
> +
> +    start_time = time.time()
> +
> +    while time.time() - start_time < TIMEOUT_SEC:
> +        events = sel.select()
> +        for key, mask in events:
> +            key.data(key.fileobj)
> +
> +    # --------------------------------------------------------------------
> +    # Clean Up
> +    #
> +    # Stop the Camera, release resources and stop the CameraManager.
> +    # libcamera has now released all resources it owned.
> +
> +    camera.stop()
> +    camera.release()
> +
> +    return 0
> +
> +
> +if __name__ == '__main__':
> +    sys.exit(main())

On 06/06/2022 15:07, Laurent Pinchart wrote:

>> +def handle_camera_event(cm):
>> +    # cm.get_ready_requests() will not block here, as we know there is an event
>> +    # to read.
>> +
>> +    reqs = cm.get_ready_requests()
>> +
>> +    # Process the captured frames
>> +
>> +    for req in reqs:
>> +        process_request(req)
> 
> This got me to think a bit more about event handling. libcamera will
> expose other events (such as frame start, error events, ...). What would
> you think of replacing get_ready_requests() with a handle_events()
> function that would take a set of callbacks for different types of
> events ? Or we could add handle_request, handle_sof, ... properties to
> CameraManager, to store the event handlers, which would still be called
> by handle_events().

I think that makes sense. Not sure if it'd be properties or giving the 
callbacks in parameters, but something like that. Let's break the API 
again! ;)

We probably want to have the order of events preserved, so we need a 
single queue of events. So maybe get_events() instead of 
get_ready_requests(), and on top we might have handle_events() which 
gets the events and calls the handler based on the event type.

>> +    # --------------------------------------------------------------------
>> +    # Start Capture
>> +    #
>> +    # In order to capture frames the Camera has to be started and
>> +    # Request queued to it. Enough Request to fill the Camera pipeline
>> +    # depth have to be queued before the Camera start delivering frames.
>> +    #
>> +    # When a Request has been completed, it will be added to a list in the
>> +    # CameraManager and an event will be raised using eventfd.
>> +    #
>> +    # The list of completed Requests can be retrieved with
>> +    # CameraManager.get_ready_requests(), which will also clear the list in the
>> +    # CameraManager.
>> +    #
>> +    # The eventfd can be retrieved from CameraManager.event_fd, and the fd can
> 
> I know you renamed this from fd to event_fd recently, but I'm thinking

It was 'efd' before, not 'fd'.

> about going back to fd. The rationale is that it needs to be an fd on
> which the application can select(), but the fact that it's an event_fd
> is an implementation detail.

Note that 'event_fd' does not refer to it being a Linux eventfd, but 
rather it being an fd that it used to wait for events.

I'm not strictly against the change, though, but 'fd' sounds a bit vague 
to me.

  Tomi

Hi Tomi,

On Mon, Jun 06, 2022 at 03:56:00PM +0300, Tomi Valkeinen wrote:
> On 06/06/2022 15:07, Laurent Pinchart wrote:
> 
> >> +def handle_camera_event(cm):
> >> +    # cm.get_ready_requests() will not block here, as we know there is an event
> >> +    # to read.
> >> +
> >> +    reqs = cm.get_ready_requests()
> >> +
> >> +    # Process the captured frames
> >> +
> >> +    for req in reqs:
> >> +        process_request(req)
> > 
> > This got me to think a bit more about event handling. libcamera will
> > expose other events (such as frame start, error events, ...). What would
> > you think of replacing get_ready_requests() with a handle_events()
> > function that would take a set of callbacks for different types of
> > events ? Or we could add handle_request, handle_sof, ... properties to
> > CameraManager, to store the event handlers, which would still be called
> > by handle_events().
> 
> I think that makes sense. Not sure if it'd be properties or giving the 
> callbacks in parameters, but something like that. Let's break the API 
> again! ;)

:-)

> We probably want to have the order of events preserved, so we need a 
> single queue of events. So maybe get_events() instead of 
> get_ready_requests(), and on top we might have handle_events() which 
> gets the events and calls the handler based on the event type.

Sounds good.

> >> +    # --------------------------------------------------------------------
> >> +    # Start Capture
> >> +    #
> >> +    # In order to capture frames the Camera has to be started and
> >> +    # Request queued to it. Enough Request to fill the Camera pipeline
> >> +    # depth have to be queued before the Camera start delivering frames.
> >> +    #
> >> +    # When a Request has been completed, it will be added to a list in the
> >> +    # CameraManager and an event will be raised using eventfd.
> >> +    #
> >> +    # The list of completed Requests can be retrieved with
> >> +    # CameraManager.get_ready_requests(), which will also clear the list in the
> >> +    # CameraManager.
> >> +    #
> >> +    # The eventfd can be retrieved from CameraManager.event_fd, and the fd can
> > 
> > I know you renamed this from fd to event_fd recently, but I'm thinking
> 
> It was 'efd' before, not 'fd'.
> 
> > about going back to fd. The rationale is that it needs to be an fd on
> > which the application can select(), but the fact that it's an event_fd
> > is an implementation detail.
> 
> Note that 'event_fd' does not refer to it being a Linux eventfd, but 
> rather it being an fd that it used to wait for events.
> 
> I'm not strictly against the change, though, but 'fd' sounds a bit vague 
> to me.

You're right, let's keep event_fd.