From patchwork Mon Dec 13 15:22:14 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Plowman X-Patchwork-Id: 15152 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id C2D11BDB13 for ; Mon, 13 Dec 2021 15:22:25 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 1DC6B60894; Mon, 13 Dec 2021 16:22:25 +0100 (CET) Authentication-Results: lancelot.ideasonboard.com; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=raspberrypi.com header.i=@raspberrypi.com header.b="EgQ5wMOG"; dkim-atps=neutral Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 27A2460868 for ; Mon, 13 Dec 2021 16:22:23 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id a9so27648459wrr.8 for ; Mon, 13 Dec 2021 07:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=n4ylPtirDjzrDsOVDw6Cw22CrPM0WbCJz/95nrdlGOY=; b=EgQ5wMOGYAfguTevB62KCGjAyh+jMJFEmpEZXDa0lJZSTBSOmO/JkaCpsOT6LFqjL5 txQ+mbFL2MPG/UI6ICYaOIvmKoo4gfISe145eryFel+EHxYXpBY4Ut1V9XwghC93AsOg w0sPrSDlzUzPZdi1PMAy8aenMU6wIPuupN684qhjgtNhtExN9CZwj2yTbvy0skLS1CtQ h5YtYy/i3/vRE7LXNZ5uajHQV42Y3H0si2Cn2WCyk8+xz5vCTTjtfpoUkWUrgAwyxeGO HYfPPUrvnXsHC2tIHtw2becMOljbdGx31Pl2oBthoBRe3DWKpPr5EGrLMMULaGVzoTw5 Vlkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=n4ylPtirDjzrDsOVDw6Cw22CrPM0WbCJz/95nrdlGOY=; b=ozsJlpjtJ3afb086W92Or58NBSeFlcITUb0Ca22cWlJuPG2gSKPo6kI3fcSKNT90tJ 60vxmgEY1aQ731f07yz7pACH5cTCHhcCnFxMoGz9W+y65Qs8XoaqAE/y5GhDNB8ANQrg 1XZEAXWyd6/nWi1fORMvmLGseo4ZLMcL6GjRAlVehhCb1xWq/BWGaAOQr5rn+rics5VY 0rfQfkoVIShsS7bCkafZarGHO0UPPWsg+cVH/IItXdrARCIJBQ7jz+ncTRwaxiIZRb6F MxFO3Dmqp9J8Fxl9vCSbWJi2SItoDEqTAxIcMYT8ZVfm/FAaTVFlE2SsFuDv/IxQabya rB2g== X-Gm-Message-State: AOAM53100gpYZzEnlm2YbiQ+0g/2dvWF/u0TQ06HCxwZjgb8aFKjI0AR L6abEdj4synPS6IUCTMHj53aQGin0YYO4Q== X-Google-Smtp-Source: ABdhPJzRkVxuvDDLB+aH/TOKOlYmGLdBU9Y4KCqeo+hzhaDjfDo3gnz0Yy5kxsUTgFAaEUmLLG/R6w== X-Received: by 2002:adf:f088:: with SMTP id n8mr31711844wro.411.1639408942365; Mon, 13 Dec 2021 07:22:22 -0800 (PST) Received: from pi4-davidp.pitowers.org ([2a00:1098:3142:14:e4a2:3070:eea4:e434]) by smtp.gmail.com with ESMTPSA id u2sm13001060wrs.17.2021.12.13.07.22.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Dec 2021 07:22:21 -0800 (PST) From: David Plowman To: libcamera-devel@lists.libcamera.org Date: Mon, 13 Dec 2021 15:22:14 +0000 Message-Id: <20211213152215.17584-1-david.plowman@raspberrypi.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Subject: [libcamera-devel] [RFC PATCH 0/1] Autofocus controls X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" Hi everyone I thought it was time for a slightly more formal API proposal for AF (autofocus). I've sent a patch listing all the new controls that I think we would need. These controls cover both the use-cases that I can imagine we (Raspberry Pi) would expect, and I think it covers all the Android use-cases too. Nonetheless, I think a few words of additional discussion and questions are warranted. 1. AfState This closely follows what Android does, only Android duplicates them all, once for "passive" (aka. continuous) AF and once for "active" (user-triggered) AF. I can't really see why duplicating them would be necessary, it seems pretty clear to me what mode we're in, but of course we could if there is a good reason. I wondered a bit about having an "Error" state. Maybe that would get reported if the AfWindow rectangles are ill-defined? 2. AfWindow Allowing applications to set the AF windows seems required. For example, you might be running some kind of object or face detector, and then you want to feed those results back to the AF algorithm. I was unsure what units to use for the Rectangles. It seemed to me that you'd want the rectangles automatically to follow whatever ScalerCrop you are using. For example, doing digital zoom and leaving the focus windows in a part of the image you can't see seems particularly unhelpful! So anyway, I went with the units being "a proportion of the ScalerCrop region". Can we think of something better? Would floating point Rectangles be less annoying? 3. AfMode As you probably already know, I'm not really seeing the need for an "off" mode as it seems the same as "auto" to me - so I didn't define one. One thing I wondered about was "pausing" CAF (continuous AF). You might want to let it run, then "pause" for a moment to take some captures, and then let it re-start from where it was previously. How to accomplish this? We could have a separate "pause" control, just for CAF. Or I've suggested that you could set the mode back to "auto" which would have the same effect. But then how would you go back to CAF "from where it left off" as opposed to letting it re-start as though it wasn't running before? Maybe the "pause" control isn't such a bad idea. 4. LensPosition I've proposed using the lens driver's units for controlling the lens position. It's easy and naturally mimics what we tend to do for exposure/gain. Another option would be to go a bit more Android-y and insist that zero means "infinity". Android seems to categorise lenses into "calibrated" and "uncalibrated" types. For the latter type, it looks like pretty much the only stipulation is that zero means "infinity". For "calibrated" lenses the units are formally defined to be dioptres, but I'm thinking that we don't need to go there right now. There's also the question of exactly where we get the lens range from. It will be different for each module, even ones using the same lens and/or driver - it will in each case be a different subset of the range that the driver advertises. But I think that's not a question for this control API. Hopefully all that's enough to start taking this forward. There are of course lots of points of detail to think about here, but clearly the "big picture" is most important in the first instance. Thanks! David David Plowman (1): libcamera: controls: Controls for driving AF (autofocus) algorithms src/libcamera/control_ids.yaml | 227 ++++++++++++++++++++++++--------- 1 file changed, 167 insertions(+), 60 deletions(-)