[libcamera-devel] [PATCH 08/14] py: move conversion funcs to libcamera.utils

[Tomi Valkeinen]

On 17/05/2022 11:23, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Mon, May 16, 2022 at 05:10:16PM +0300, Tomi Valkeinen wrote:
>> cam_qt.py has a bunch of utility functions for pixel format conversions.
>> Create a new libcamera submodule for these.
> 
> I'm not sure I like this much. Do we really want to create a format
> conversion library that will we'll eventually have to maintain with a
> stable ABI ?

That's a good question. I've been thinking a lot about what exactly 
should be bindings module contain.

Just the bare-bone bindings? Then it's probably not very pythonic and 
not easy to use.

Or try to keep to the bare bones feature-wise (i.e. no conversions 
features like this), but add convenience features to make it look more 
pythonic? Then the API deviates from the C++ API.

Or bare-bone bindings, but a separate, pure python library on top? What 
do we call the libraries, then =). And if everyone uses the pure python 
lib, what is the point of a separate bare-bone library?

I'm currently thinking that this all should be under one libcamera 
module. "libcamera._libcamera" is the bare-bones native bindings (as it 
already is), and libcamera module exposes a more pythonic version with 
some helper classes (like the MappedFrameBuffer class we already have). 
We can then have other submodules, which are not needed for libcamera 
use, but provide extra features, like libcamera.utils. Perhaps 
MappedFrameBuffer should also be moved there.

I think the main libcamera and the libcamera.utils can be considered 
separate modules, and I don't see a problem with having stable libcamera 
API, but libcamera.utils is not stable. But to make it more obvious, we 
could as well have, say, libcamera.experimental module.

That said, conversion functionality is something I'd expect to find from 
some other Python module. But if I recall right, I couldn't find a 
working bayer conversion.

  Tomi