From patchwork Wed Mar 24 11:44:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Plowman X-Patchwork-Id: 11691 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 F3902C32E5 for ; Wed, 24 Mar 2021 11:44:21 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id 35FF768D69; Wed, 24 Mar 2021 12:44:21 +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="V+moEZR1"; dkim-atps=neutral Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 41019602E3 for ; Wed, 24 Mar 2021 12:44:19 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id ce10so32322061ejb.6 for ; Wed, 24 Mar 2021 04:44:19 -0700 (PDT) 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=awcwv7zsUa3zN0b0ABLzu8wgT9s3NziYbE3rxcc4AaE=; b=V+moEZR1IpnGK0n+g18Z54fDeHjWXChcOjMj6c8/g5trMju8ejQqFxYxQ7Ki/HnKkl GWj9/JdJL4ZnFGNfNaSIn+1hTI6rRfMWHTK+CK6zJci3jMF+jUVEkXLdvmKwvu3D8B+0 MLuYT2tB3EeVH8CKH8pr9aj3QzZiR+ZjYQ/q2hMZeO95aoSriEIo8nEPQfdQTMya4ZAb KyRW/vE8EVVNdZpYrmXJgswp7UGh0cSwa/4IijJy46On1RW3QVTSi285w7R41kS1pIxN ZO2/ulpMuRuvLhyce8N4hHQ3zhk2QijFrw8nTpxENBFXXfz8Y9XidZ5sNiAhPAv6dBHN MfLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=awcwv7zsUa3zN0b0ABLzu8wgT9s3NziYbE3rxcc4AaE=; b=bzRzCoe7a1yBQbjdneeMG+paSb7pNg/IQA7vwLu7/2rEtEPP/VReMcEmTFmVbnLiwM z5JIvvntU7qQlnT10nVuhX61p2fFHHWreJ2NhHtxKTs6mioc/1VRXZXSf+budD3VKCyz JTYEp6Lr3dQbVI9K9TOeuXwZejlQNvaDvXukpZMmWuYtzNTgUXwUqEEB2NLvSkk6lyMG m+e/jLpr7D29y3xFkHkpSCs+tk894kMwMiBArjUAitdYDmTkNFAaVFzQ51WBZEOl6lDN 2KhHX4Tha4bKy4QCWCJUsT2NmqDx0BRVtXwoe4qX1d16Mt4m8hcckzya6r6sKyUQao1t 5Vsg== X-Gm-Message-State: AOAM5311sVrqeEkxzPeiDyKlPsz0nlR4+91+svnXAJe0HTkwUux+TjYV R0+hKpQItyRbyyqLuKpLYRVe+52916ufYQ== X-Google-Smtp-Source: ABdhPJzHfK6DJXZED63dRQk/2Z7ZEh80J1CcBjlWc0nr1zr+8Q5CNXG3mtqucd4DEW6MDXSm5aoKCw== X-Received: by 2002:a17:907:7637:: with SMTP id jy23mr3098980ejc.12.1616586258410; Wed, 24 Mar 2021 04:44:18 -0700 (PDT) Received: from pi4-davidp.lan (plowpeople3.plus.com. [80.229.223.72]) by smtp.gmail.com with ESMTPSA id c17sm1054781edw.32.2021.03.24.04.44.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Mar 2021 04:44:18 -0700 (PDT) From: David Plowman To: libcamera-devel@lists.libcamera.org Date: Wed, 24 Mar 2021 11:44:13 +0000 Message-Id: <20210324114415.19866-1-david.plowman@raspberrypi.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Subject: [libcamera-devel] [PATCH 0/2] Raspberry Pi: handle sensors more flexibly 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 Here are a couple more patches aimed at allowing us to deal more flexibly with "interesting" sensors. The first patch simply makes the CamHelper's exposure-related methods virtual. This gives greater flexibility on how we deal with sensors where different modes have different signal levels. Differences between modes can be accounted for with the gain methods (already virtual), in the exposure (with this change), or via a combination of the two. Note that another solution to this involves fiddling around with the AGC. It would have to know that modes can have different "base signal levels", and account for the difference. I'm still in several minds about whether I want to do this, so this change gives us options in the meantime, and doesn't preclude messing with the AGC later if we wish. The second commit takes the view that if sensors seem to be asking for the red/blue colour gains, then we should tell them. I guess there's a risk that some sensors might seem to want these numbers, but we find that we don't want to tell them. If that happens maybe the CamHelper would have to tell us what to do, but this approach seems reasonable to me at this point. I also apply a fixed 256x multiplier to the colour gains before passing them to the control. I don't think V4L2 docs mandate any particular scale here? Maybe there's an argument for another CamHelper function "ColourGainCode", or something like that. Thoughts and suggestions welcome as always. Thanks! David David Plowman (2): ipa: raspberrypi: Make CamHelper exposure methods virtual ipa: raspberrypi: Update sensor's RED/BLUE balance controls when present src/ipa/raspberrypi/cam_helper.hpp | 4 ++-- src/ipa/raspberrypi/raspberrypi.cpp | 17 ++++++++++++++--- .../pipeline/raspberrypi/raspberrypi.cpp | 9 +++++++++ 3 files changed, 25 insertions(+), 5 deletions(-)