[libcamera-devel,v2,10/11,DNI] utils: tuning: Add full libtuning raspberrypi tuning script
diff mbox series

Message ID 20221022062310.2545463-11-paul.elder@ideasonboard.com
State New
Headers show
  • utils: tuning: Add a new tuning infrastructure
Related show

Commit Message

Paul Elder Oct. 22, 2022, 6:23 a.m. UTC
Add a tuning script for raspberrypi that uses libtuning. This reproduces
what ctt does (albeit with less logging for now), but with common
components factored out into libtuning so that tuning scripts for other
platforms can reuse them.

Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>

Changes in v2:
- add SPDX and copyright

This is incomplete, hence the DNI.
 utils/tuning/raspberrypi.py | 44 +++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 utils/tuning/raspberrypi.py

diff mbox series

diff --git a/utils/tuning/raspberrypi.py b/utils/tuning/raspberrypi.py
new file mode 100644
index 00000000..8e963743
--- /dev/null
+++ b/utils/tuning/raspberrypi.py
@@ -0,0 +1,44 @@ 
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright (C) 2022, Paul Elder <paul.elder@ideasonboard.com>
+# raspberrypi.py - Tuning script for raspberrypi
+import sys
+import libtuning as lt
+from libtuning.modules import AWB
+from libtuning.parsers import RaspberryPiParser
+from libtuning.generators import RaspberryPiOutput
+from raspberrypi.alsc import ALSC
+tuner = lt.Camera('Raspberry Pi')
+# These modules can also be custom modules. libtuning will come with utilities
+# for handling stuff like images, so there shouldn't be too much boilerplate
+# involved in creating custom modules, though I don't yet have a concrete
+# vision on how custom implementations of modules would look.
+# Other tuning modules can be added like so.
+# The order that the tuning modules will be executed is determined by the order
+# that they're added.
+# This is kind of an implementation detail, but the "context" is saved
+# internally in lt.Camera, so modules that are added (and therefore executed)
+# later can use the output of the previous modules. I'm thinking that a module
+# that depends on values from another module has two modes of execution, for
+# when those values are available and another for when they're not. Not quite
+# sure concretely how to handle this yet.
+tuner.add(AWB(  # module parameters
+# The order of the output doesn't necessarily have to be the same as the order
+# of input, which is specified by the order of adding the modules above.
+tuner.setOutputOrder([AWB, ALSC])