[{"id":16160,"web_url":"https://patchwork.libcamera.org/comment/16160/","msgid":"<20210409084056.elpvycb5pe5wtuvc@uno.localdomain>","date":"2021-04-09T08:40:56","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":3,"url":"https://patchwork.libcamera.org/api/people/3/","name":"Jacopo Mondi","email":"jacopo@jmondi.org"},"content":"Hi Hiro,\n\nOn Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> The control is used to report available sensor test pattern modes\n> and also specify the mode to sensor.\n>\n> Signed-off-by: Hirokazu Honda \n> ---\n> src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> 1 file changed, 59 insertions(+)\n>\n> diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> index b4771f9d..be2f710a 100644\n> --- a/src/libcamera/control_ids.yaml\n> +++ b/src/libcamera/control_ids.yaml\n> @@ -608,4 +608,63 @@ controls:\n> detection, additional format conversions etc) count as an additional\n> pipeline stage.\n>\n> + - SensorTestPatternMode:\n> + type: int32_t\n> + draft: true\n> + description: |\n> + Control to select the sensor test pattern mode. Currently identical to\n> + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> +\n> + Mode of operation for the test pattern mode.\n\nYou can drop this line, but it's ok\n\n> + enum:\n> + - name: SensorTestPatternModeOff\n> + value: 0\n> + description: |\n> + No test pattern mode is used. The camera device returns from the\n> + image sensor.\n> + - name: SensorTestPatternModeSolidColor\n> + value: 1\n> + description: |\n> + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> + color channel.\n> + - name: SensorTestPatternModeColorBars\n> + value: 2\n> + description: |\n> + All pixel data is replaced with an 8-bar color pattern. The vertical\n> + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> + magenta, red, blue and black. Each bar should take up 1/8 of the\n> + sensor pixel array width. When this is not possible, the bar size\n> + should be rounded down to the nearest integer and the pattern can\n> + repeat on the right side. Each bar's height must always take up the\n> + full sensor pixel array height.\n> + - name: SensorTestPatternModeColorBarsFadeToGray\n> + value: 3\n> + description: |\n> + The test pattern is similar to SensorTestPatternModeColorBars,\n> + except that each bar should start at its specified color at the top\n> + and fade to gray at the bottom. Furthermore each bar is further\n> + subdevided into a left and right half. The left half should have a\n> + smooth gradient, and the right half should have a quantized\n> + gradient. In particular, the right half's should consist of blocks\n> + of the same color for 1/16th active sensor pixel array width. The\n> + least significant bits in the quantized gradient should be copied\n> + from the most significant bits of the smooth gradient. The height of\n> + each bar should always be a multiple of 128. When this is not the\n> + case, the pattern should repeat at the bottom of the image.\n> + - name: SensorTestPatternModePn9\n> + value: 4\n> + description: |\n> + All pixel data is replaced by a pseudo-random sequence generated\n> + from a PN9 512-bit sequence (typically implemented in hardware with\n> + a linear feedback shift register). The generator should be reset at\n> + the beginning of each frame, and thus each subsequent raw frame with\n> + this test pattern should be exactly the same as the last.\n> + - name: SensorTestPatternModeCustom1\n> + value: 5\n> + description: |\n> + The first custom test pattern. All custom patterns that are\n> + available only on this camera device are at least this numeric\n> + value. All of the custom test patterns will be static (that is the\n> + raw image must not vary from frame to frame).\n> +\n\nThanks for the details descriptions. They're not strictly necessary as\nwe explicitly refer to ANDROID_SENSOR_TEST_PATTERN_MODE in the control\ndefinition, but doesn't hurt to have them here.\n\nReviewed-by: Jacopo Mondi \n\nThanks\n j\n\n> ...\n> --\n> 2.31.1.295.g9ea45b61b8-goog\n>\n> _______________________________________________\n> libcamera-devel mailing list\n> libcamera-devel@lists.libcamera.org\n> https://lists.libcamera.org/listinfo/libcamera-devel","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id B939BBD1F6\n\tfor ;\n\tFri, 9 Apr 2021 08:40:21 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 21BCA687F5;\n\tFri, 9 Apr 2021 10:40:21 +0200 (CEST)","from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net\n\t[217.70.183.194])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A484C687D6\n\tfor ;\n\tFri, 9 Apr 2021 10:40:19 +0200 (CEST)","from uno.localdomain (93-34-118-233.ip49.fastwebnet.it\n\t[93.34.118.233]) (Authenticated sender: jacopo@jmondi.org)\n\tby relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 0B3154000E;\n\tFri, 9 Apr 2021 08:40:18 +0000 (UTC)"],"X-Originating-IP":"93.34.118.233","Date":"Fri, 9 Apr 2021 10:40:56 +0200","From":"Jacopo Mondi ","To":"Hirokazu Honda ","Message-ID":"<20210409084056.elpvycb5pe5wtuvc@uno.localdomain>","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20210409043208.1823330-2-hiroh@chromium.org>","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":16197,"web_url":"https://patchwork.libcamera.org/comment/16197/","msgid":"","date":"2021-04-13T00:37:03","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Hiro,\n\nThank you for the patch.\n\nOn Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> The control is used to report available sensor test pattern modes\n> and also specify the mode to sensor.\n> \n> Signed-off-by: Hirokazu Honda \n> ---\n> src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> 1 file changed, 59 insertions(+)\n> \n> diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> index b4771f9d..be2f710a 100644\n> --- a/src/libcamera/control_ids.yaml\n> +++ b/src/libcamera/control_ids.yaml\n> @@ -608,4 +608,63 @@ controls:\n> detection, additional format conversions etc) count as an additional\n> pipeline stage.\n> \n> + - SensorTestPatternMode:\n\nDoes this need to be limited to the sensor, or can we also produce the\ntest pattern on the ISP side ? I'm thinking about SoCs that have a test\npattern generator in the inline ISP, in the Bayer domain, just after the\nCSI-2 receiver.\n\n> + type: int32_t\n> + draft: true\n> + description: |\n> + Control to select the sensor test pattern mode. Currently identical to\n> + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> +\n> + Mode of operation for the test pattern mode.\n> + enum:\n> + - name: SensorTestPatternModeOff\n> + value: 0\n> + description: |\n> + No test pattern mode is used. The camera device returns from the\n> + image sensor.\n> + - name: SensorTestPatternModeSolidColor\n> + value: 1\n> + description: |\n> + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> + color channel.\n\nHow do we pick the colour ?\n\n> + - name: SensorTestPatternModeColorBars\n> + value: 2\n> + description: |\n> + All pixel data is replaced with an 8-bar color pattern. The vertical\n> + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> + magenta, red, blue and black. Each bar should take up 1/8 of the\n> + sensor pixel array width. When this is not possible, the bar size\n> + should be rounded down to the nearest integer and the pattern can\n> + repeat on the right side. Each bar's height must always take up the\n> + full sensor pixel array height.\n> + - name: SensorTestPatternModeColorBarsFadeToGray\n> + value: 3\n> + description: |\n> + The test pattern is similar to SensorTestPatternModeColorBars,\n> + except that each bar should start at its specified color at the top\n> + and fade to gray at the bottom. Furthermore each bar is further\n> + subdevided into a left and right half. The left half should have a\n> + smooth gradient, and the right half should have a quantized\n> + gradient. In particular, the right half's should consist of blocks\n> + of the same color for 1/16th active sensor pixel array width. The\n> + least significant bits in the quantized gradient should be copied\n> + from the most significant bits of the smooth gradient. The height of\n> + each bar should always be a multiple of 128. When this is not the\n> + case, the pattern should repeat at the bottom of the image.\n\nDo you know what sensor implements this ? I've never seen it before.\n\n> + - name: SensorTestPatternModePn9\n> + value: 4\n> + description: |\n> + All pixel data is replaced by a pseudo-random sequence generated\n> + from a PN9 512-bit sequence (typically implemented in hardware with\n> + a linear feedback shift register). The generator should be reset at\n> + the beginning of each frame, and thus each subsequent raw frame with\n> + this test pattern should be exactly the same as the last.\n\nSame question.\n\n> + - name: SensorTestPatternModeCustom1\n> + value: 5\n> + description: |\n> + The first custom test pattern. All custom patterns that are\n> + available only on this camera device are at least this numeric\n> + value. All of the custom test patterns will be static (that is the\n> + raw image must not vary from frame to frame).\n\nCould we figure out a better way to implement support for custom test\npattern modes ? Having Custom1 immediately following Pn9 won't allow for\nnew patterns to be defined. Starting at a higher value would be an\noption, but I'd like to find a good way to handle custom values, for all\ncontrols that have the same issue.\n\n> +\n> ...","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 20293BD224\n\tfor ;\n\tTue, 13 Apr 2021 00:37:56 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 97F81687EC;\n\tTue, 13 Apr 2021 02:37:55 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 5FEDA605AE\n\tfor ;\n\tTue, 13 Apr 2021 02:37:53 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id C38FC6F2;\n\tTue, 13 Apr 2021 02:37:52 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"IAzTMYW0\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1618274273;\n\tbh=WON55ZNon+bRfDnqBolZmoz5sEdLtnqd07lyAUjLaY8=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=IAzTMYW0F6PZDKCjWIxEdHYPx8vH8zjMP/M4Nf9s3hl76vRdkCIsIwfhxvFS59Dts\n\tYz1pL+d1btOthuzGJ7yYOH7MdGEEB4BCft/A0q1O4qyZfVRQ5qfnpXObM4YKtRppJU\n\tsCfmRlQVWoyPQ6v0Pnk3q895dlRa4IjM91bltat8=","Date":"Tue, 13 Apr 2021 03:37:03 +0300","From":"Laurent Pinchart ","To":"Hirokazu Honda ","Message-ID":"","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"<20210409043208.1823330-2-hiroh@chromium.org>","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera-devel@lists.libcamera.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":16224,"web_url":"https://patchwork.libcamera.org/comment/16224/","msgid":"","date":"2021-04-13T08:10:39","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":63,"url":"https://patchwork.libcamera.org/api/people/63/","name":"Hirokazu Honda","email":"hiroh@chromium.org"},"content":"On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart\n wrote:\n>\n> Hi Hiro,\n>\n> Thank you for the patch.\n>\n> On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> > The control is used to report available sensor test pattern modes\n> > and also specify the mode to sensor.\n> >\n> > Signed-off-by: Hirokazu Honda \n> > ---\n> > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> > 1 file changed, 59 insertions(+)\n> >\n> > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> > index b4771f9d..be2f710a 100644\n> > --- a/src/libcamera/control_ids.yaml\n> > +++ b/src/libcamera/control_ids.yaml\n> > @@ -608,4 +608,63 @@ controls:\n> > detection, additional format conversions etc) count as an additional\n> > pipeline stage.\n> >\n> > + - SensorTestPatternMode:\n>\n> Does this need to be limited to the sensor, or can we also produce the\n> test pattern on the ISP side ? I'm thinking about SoCs that have a test\n> pattern generator in the inline ISP, in the Bayer domain, just after the\n> CSI-2 receiver.\n>\n\nShall I just name TestPatternMode?\n\n> > + type: int32_t\n> > + draft: true\n> > + description: |\n> > + Control to select the sensor test pattern mode. Currently identical to\n> > + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> > +\n> > + Mode of operation for the test pattern mode.\n> > + enum:\n> > + - name: SensorTestPatternModeOff\n> > + value: 0\n> > + description: |\n> > + No test pattern mode is used. The camera device returns from the\n> > + image sensor.\n> > + - name: SensorTestPatternModeSolidColor\n> > + value: 1\n> > + description: |\n> > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> > + color channel.\n>\n> How do we pick the colour ?\n>\n> > + - name: SensorTestPatternModeColorBars\n> > + value: 2\n> > + description: |\n> > + All pixel data is replaced with an 8-bar color pattern. The vertical\n> > + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> > + magenta, red, blue and black. Each bar should take up 1/8 of the\n> > + sensor pixel array width. When this is not possible, the bar size\n> > + should be rounded down to the nearest integer and the pattern can\n> > + repeat on the right side. Each bar's height must always take up the\n> > + full sensor pixel array height.\n> > + - name: SensorTestPatternModeColorBarsFadeToGray\n> > + value: 3\n> > + description: |\n> > + The test pattern is similar to SensorTestPatternModeColorBars,\n> > + except that each bar should start at its specified color at the top\n> > + and fade to gray at the bottom. Furthermore each bar is further\n> > + subdevided into a left and right half. The left half should have a\n> > + smooth gradient, and the right half should have a quantized\n> > + gradient. In particular, the right half's should consist of blocks\n> > + of the same color for 1/16th active sensor pixel array width. The\n> > + least significant bits in the quantized gradient should be copied\n> > + from the most significant bits of the smooth gradient. The height of\n> > + each bar should always be a multiple of 128. When this is not the\n> > + case, the pattern should repeat at the bottom of the image.\n>\n> Do you know what sensor implements this ? I've never seen it before.\n>\n\nI think ov13858 produces this as \"Vertical Color Bar Type 2\".\nIMX219 also produces as \"Grey Color Bars\".\n\n> > + - name: SensorTestPatternModePn9\n> > + value: 4\n> > + description: |\n> > + All pixel data is replaced by a pseudo-random sequence generated\n> > + from a PN9 512-bit sequence (typically implemented in hardware with\n> > + a linear feedback shift register). The generator should be reset at\n> > + the beginning of each frame, and thus each subsequent raw frame with\n> > + this test pattern should be exactly the same as the last.\n>\n> Same question.\n>\n\nIMX219 produces \"PN9\".\n\n> > + - name: SensorTestPatternModeCustom1\n> > + value: 5\n> > + description: |\n> > + The first custom test pattern. All custom patterns that are\n> > + available only on this camera device are at least this numeric\n> > + value. All of the custom test patterns will be static (that is the\n> > + raw image must not vary from frame to frame).\n>\n> Could we figure out a better way to implement support for custom test\n> pattern modes ? Having Custom1 immediately following Pn9 won't allow for\n> new patterns to be defined. Starting at a higher value would be an\n> option, but I'd like to find a good way to handle custom values, for all\n> controls that have the same issue.\n>\n\nThat's a good question. I think we're not so interested in custom\nvalues right now.\nSo we can drop this now. Is it fine?\n\n\n> > +\n> > ...\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 09DCBBD224\n\tfor ;\n\tTue, 13 Apr 2021 08:10:53 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 44D0468800;\n\tTue, 13 Apr 2021 10:10:52 +0200 (CEST)","from mail-ej1-x629.google.com (mail-ej1-x629.google.com\n\t[IPv6:2a00:1450:4864:20::629])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 17274687F3\n\tfor ;\n\tTue, 13 Apr 2021 10:10:51 +0200 (CEST)","by mail-ej1-x629.google.com with SMTP id n2so24449573ejy.7\n\tfor ;\n\tTue, 13 Apr 2021 01:10:51 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"CFtQ5tJi\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=ykGvKhabgt0D13i2s+3jVd+scoPmslLq9xBWm7EDwo0=;\n\tb=CFtQ5tJiHxaGQNCSnDjHZhkXvjBbkrKrW/lQSLbfTJ3ljqK/d3vvJwJSRXNuqy55HL\n\tL0OYft9/Kl0cueSvjfu97y+L0fmvFzZZqSY4kDuyz2WZKj93P8uJFH+wfdKdsZUBMQ+f\n\tUBOw4njXu9ECZfoJnFvDxG+o6Acj9qGPPWUvw=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=ykGvKhabgt0D13i2s+3jVd+scoPmslLq9xBWm7EDwo0=;\n\tb=bvMumHTWeku3x2DIOVlotuoxyYVfoCRaqLPrfGFTEmWIS+Aww0PA9p0IC4vNd9zoqe\n\tXrg6YXjsXTVu/clZcbbw3mhYxJWpz7JKfpT+ze64DF6WJd0Av8uXSbscB7do+upuGFUP\n\twzxO6oA7I7L8fvWZ8qWOk1+p0f3vWZ+3uiiEUJTvlQ9T1ZHoyPtiMDMTrtCfSKFce/XK\n\tkiTREjz0UporkWjRZJlbOX4HhDtExiqOO7+HTHzijyi2BmG4ST3ovqEpQWfGtUuaMRNh\n\thMcOxDGn0pUpgmT96f/JVTj3ucS5E6qnI3kYLJfrkz9SvEkCuUBQidV4Edj/pwsBUA72\n\tN14g==","X-Gm-Message-State":"AOAM530r0MgtrmY4Q5a6YQ0wZ7Jk6ZZEqiU5/aDAPS8wyKd4gdQGO/Em\n\t9kihECrI3Wt7EfxFsdtZ4HoaT825h1DxFJQ98BF2gI9VecM=","X-Google-Smtp-Source":"ABdhPJw5q4kacQxV938XeYO6UNOPGOcDVtBKWv8n66qyEJK9tq40iKfpTC5IPN3irZjcT1HJLJn5pb8cojL+NeKR6Eg=","X-Received":"by 2002:a17:906:80d1:: with SMTP id\n\ta17mr11535578ejx.55.1618301450625; \n\tTue, 13 Apr 2021 01:10:50 -0700 (PDT)","MIME-Version":"1.0","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>\n\t","In-Reply-To":"","From":"Hirokazu Honda ","Date":"Tue, 13 Apr 2021 17:10:39 +0900","Message-ID":"","To":"Laurent Pinchart ","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":16225,"web_url":"https://patchwork.libcamera.org/comment/16225/","msgid":"","date":"2021-04-13T08:26:13","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":63,"url":"https://patchwork.libcamera.org/api/people/63/","name":"Hirokazu Honda","email":"hiroh@chromium.org"},"content":"On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda wrote:\n>\n> On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart\n> wrote:\n> >\n> > Hi Hiro,\n> >\n> > Thank you for the patch.\n> >\n> > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> > > The control is used to report available sensor test pattern modes\n> > > and also specify the mode to sensor.\n> > >\n> > > Signed-off-by: Hirokazu Honda \n> > > ---\n> > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> > > 1 file changed, 59 insertions(+)\n> > >\n> > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> > > index b4771f9d..be2f710a 100644\n> > > --- a/src/libcamera/control_ids.yaml\n> > > +++ b/src/libcamera/control_ids.yaml\n> > > @@ -608,4 +608,63 @@ controls:\n> > > detection, additional format conversions etc) count as an additional\n> > > pipeline stage.\n> > >\n> > > + - SensorTestPatternMode:\n> >\n> > Does this need to be limited to the sensor, or can we also produce the\n> > test pattern on the ISP side ? I'm thinking about SoCs that have a test\n> > pattern generator in the inline ISP, in the Bayer domain, just after the\n> > CSI-2 receiver.\n> >\n>\n> Shall I just name TestPatternMode?\n>\n> > > + type: int32_t\n> > > + draft: true\n> > > + description: |\n> > > + Control to select the sensor test pattern mode. Currently identical to\n> > > + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> > > +\n> > > + Mode of operation for the test pattern mode.\n> > > + enum:\n> > > + - name: SensorTestPatternModeOff\n> > > + value: 0\n> > > + description: |\n> > > + No test pattern mode is used. The camera device returns from the\n> > > + image sensor.\n> > > + - name: SensorTestPatternModeSolidColor\n> > > + value: 1\n> > > + description: |\n> > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> > > + color channel.\n> >\n> > How do we pick the colour ?\n> >\n\nThis definition is based on bayer pattern.\nAll pixels in a frame of the solid color test pattern are identical,\nlike all green.\ncf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR\n\n> > > + - name: SensorTestPatternModeColorBars\n> > > + value: 2\n> > > + description: |\n> > > + All pixel data is replaced with an 8-bar color pattern. The vertical\n> > > + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> > > + magenta, red, blue and black. Each bar should take up 1/8 of the\n> > > + sensor pixel array width. When this is not possible, the bar size\n> > > + should be rounded down to the nearest integer and the pattern can\n> > > + repeat on the right side. Each bar's height must always take up the\n> > > + full sensor pixel array height.\n> > > + - name: SensorTestPatternModeColorBarsFadeToGray\n> > > + value: 3\n> > > + description: |\n> > > + The test pattern is similar to SensorTestPatternModeColorBars,\n> > > + except that each bar should start at its specified color at the top\n> > > + and fade to gray at the bottom. Furthermore each bar is further\n> > > + subdevided into a left and right half. The left half should have a\n> > > + smooth gradient, and the right half should have a quantized\n> > > + gradient. In particular, the right half's should consist of blocks\n> > > + of the same color for 1/16th active sensor pixel array width. The\n> > > + least significant bits in the quantized gradient should be copied\n> > > + from the most significant bits of the smooth gradient. The height of\n> > > + each bar should always be a multiple of 128. When this is not the\n> > > + case, the pattern should repeat at the bottom of the image.\n> >\n> > Do you know what sensor implements this ? I've never seen it before.\n> >\n>\n> I think ov13858 produces this as \"Vertical Color Bar Type 2\".\n> IMX219 also produces as \"Grey Color Bars\".\n>\n> > > + - name: SensorTestPatternModePn9\n> > > + value: 4\n> > > + description: |\n> > > + All pixel data is replaced by a pseudo-random sequence generated\n> > > + from a PN9 512-bit sequence (typically implemented in hardware with\n> > > + a linear feedback shift register). The generator should be reset at\n> > > + the beginning of each frame, and thus each subsequent raw frame with\n> > > + this test pattern should be exactly the same as the last.\n> >\n> > Same question.\n> >\n>\n> IMX219 produces \"PN9\".\n>\n> > > + - name: SensorTestPatternModeCustom1\n> > > + value: 5\n> > > + description: |\n> > > + The first custom test pattern. All custom patterns that are\n> > > + available only on this camera device are at least this numeric\n> > > + value. All of the custom test patterns will be static (that is the\n> > > + raw image must not vary from frame to frame).\n> >\n> > Could we figure out a better way to implement support for custom test\n> > pattern modes ? Having Custom1 immediately following Pn9 won't allow for\n> > new patterns to be defined. Starting at a higher value would be an\n> > option, but I'd like to find a good way to handle custom values, for all\n> > controls that have the same issue.\n> >\n>\n> That's a good question. I think we're not so interested in custom\n> values right now.\n> So we can drop this now. Is it fine?\n>\n>\n> > > +\n> > > ...\n> >\n> > --\n> > Regards,\n> >\n> > Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id C281CBD1F6\n\tfor ;\n\tTue, 13 Apr 2021 08:26:26 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 2FB84687FE;\n\tTue, 13 Apr 2021 10:26:26 +0200 (CEST)","from mail-ed1-x535.google.com (mail-ed1-x535.google.com\n\t[IPv6:2a00:1450:4864:20::535])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id AAF50687F3\n\tfor ;\n\tTue, 13 Apr 2021 10:26:24 +0200 (CEST)","by mail-ed1-x535.google.com with SMTP id bx20so17210258edb.12\n\tfor ;\n\tTue, 13 Apr 2021 01:26:24 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"AQ0UwKLy\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=nFAZaxlQThFd6nEz28nLUSDgxIvu+YQgfIIqZP140jA=;\n\tb=AQ0UwKLyRyvrYfauzXI7fcXEYUe9f/QOpaxYsI/qqCqoG5/MEN2+0Au4TXkBcUUC5o\n\tjPe95dfDAJ5p8oEi2nZTsJ3Qt+/W4MU5oJ0nlyrzJslsExN/SqLVbHpvbSxlYb8MmNbj\n\taQiCSBtE8yjoi1rQJpvHBkHyqnk7SSds1W6k0=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=nFAZaxlQThFd6nEz28nLUSDgxIvu+YQgfIIqZP140jA=;\n\tb=HZf6J5cD+C6/+c57Wbo1QDKgq8/1U4qjLG/fuiZMjuBjDOcPtCv9tv4QS3co5dlVz2\n\t8PR8/jprIedYnSR5OFAiDD/CKClp0ei2TLx7bMjkcwrjWc9L9rlURQxDRD16NZcYzcRH\n\t7Uk6IgDgfcqNYGalJpYME92Ykzw+7udUsI7AIqv56EDO6B+mYvA6YxCmjwjNG2cn1CRC\n\t5a+7uHc6WA/cM803kWBZbnCy9TiorYLILIrMwCzqlhCikyW63Bxj0xTQREiHPDYwJC3X\n\t5LFxmefgWOpeZK7P93AI/aenaUu1kr/RPlR1v9aOPEJfH8nEdEPFrjov7iKJKtbMOmmL\n\tLs9Q==","X-Gm-Message-State":"AOAM533IvDgCklwKz5eupco1s7MQDACg+WlPJ0b7eLlNCxYI1ScqAenJ\n\tO3WZ84AKT+Ouh9Bglu5jkMq9wkfQX84bWeKKd2F8DI0TtwcgIg==","X-Google-Smtp-Source":"ABdhPJxjIXLw/L2vbIlL7HOIfg2sY9p57SSCihYvxkkljlNaJjvlCFMihpRKUYAp5vfbMDQub6aKDMxef47Uq4HVfog=","X-Received":"by 2002:a05:6402:488:: with SMTP id\n\tk8mr33437854edv.233.1618302384286; \n\tTue, 13 Apr 2021 01:26:24 -0700 (PDT)","MIME-Version":"1.0","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>\n\t\n\t","In-Reply-To":"","From":"Hirokazu Honda ","Date":"Tue, 13 Apr 2021 17:26:13 +0900","Message-ID":"","To":"Laurent Pinchart ","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":16226,"web_url":"https://patchwork.libcamera.org/comment/16226/","msgid":"","date":"2021-04-13T08:42:07","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":63,"url":"https://patchwork.libcamera.org/api/people/63/","name":"Hirokazu Honda","email":"hiroh@chromium.org"},"content":"On Tue, Apr 13, 2021 at 5:26 PM Hirokazu Honda wrote:\n>\n> On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda wrote:\n> >\n> > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart\n> > wrote:\n> > >\n> > > Hi Hiro,\n> > >\n> > > Thank you for the patch.\n> > >\n> > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> > > > The control is used to report available sensor test pattern modes\n> > > > and also specify the mode to sensor.\n> > > >\n> > > > Signed-off-by: Hirokazu Honda \n> > > > ---\n> > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> > > > 1 file changed, 59 insertions(+)\n> > > >\n> > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> > > > index b4771f9d..be2f710a 100644\n> > > > --- a/src/libcamera/control_ids.yaml\n> > > > +++ b/src/libcamera/control_ids.yaml\n> > > > @@ -608,4 +608,63 @@ controls:\n> > > > detection, additional format conversions etc) count as an additional\n> > > > pipeline stage.\n> > > >\n> > > > + - SensorTestPatternMode:\n> > >\n> > > Does this need to be limited to the sensor, or can we also produce the\n> > > test pattern on the ISP side ? I'm thinking about SoCs that have a test\n> > > pattern generator in the inline ISP, in the Bayer domain, just after the\n> > > CSI-2 receiver.\n> > >\n> >\n> > Shall I just name TestPatternMode?\n> >\n> > > > + type: int32_t\n> > > > + draft: true\n> > > > + description: |\n> > > > + Control to select the sensor test pattern mode. Currently identical to\n> > > > + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> > > > +\n> > > > + Mode of operation for the test pattern mode.\n> > > > + enum:\n> > > > + - name: SensorTestPatternModeOff\n> > > > + value: 0\n> > > > + description: |\n> > > > + No test pattern mode is used. The camera device returns from the\n> > > > + image sensor.\n> > > > + - name: SensorTestPatternModeSolidColor\n> > > > + value: 1\n> > > > + description: |\n> > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> > > > + color channel.\n> > >\n> > > How do we pick the colour ?\n> > >\n>\n> This definition is based on bayer pattern.\n> All pixels in a frame of the solid color test pattern are identical,\n> like all green.\n> cf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR\n>\n\n+Tomasz Figa Please correct me if I'm wrong.\n\n> > > > + - name: SensorTestPatternModeColorBars\n> > > > + value: 2\n> > > > + description: |\n> > > > + All pixel data is replaced with an 8-bar color pattern. The vertical\n> > > > + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> > > > + magenta, red, blue and black. Each bar should take up 1/8 of the\n> > > > + sensor pixel array width. When this is not possible, the bar size\n> > > > + should be rounded down to the nearest integer and the pattern can\n> > > > + repeat on the right side. Each bar's height must always take up the\n> > > > + full sensor pixel array height.\n> > > > + - name: SensorTestPatternModeColorBarsFadeToGray\n> > > > + value: 3\n> > > > + description: |\n> > > > + The test pattern is similar to SensorTestPatternModeColorBars,\n> > > > + except that each bar should start at its specified color at the top\n> > > > + and fade to gray at the bottom. Furthermore each bar is further\n> > > > + subdevided into a left and right half. The left half should have a\n> > > > + smooth gradient, and the right half should have a quantized\n> > > > + gradient. In particular, the right half's should consist of blocks\n> > > > + of the same color for 1/16th active sensor pixel array width. The\n> > > > + least significant bits in the quantized gradient should be copied\n> > > > + from the most significant bits of the smooth gradient. The height of\n> > > > + each bar should always be a multiple of 128. When this is not the\n> > > > + case, the pattern should repeat at the bottom of the image.\n> > >\n> > > Do you know what sensor implements this ? I've never seen it before.\n> > >\n> >\n> > I think ov13858 produces this as \"Vertical Color Bar Type 2\".\n> > IMX219 also produces as \"Grey Color Bars\".\n> >\n> > > > + - name: SensorTestPatternModePn9\n> > > > + value: 4\n> > > > + description: |\n> > > > + All pixel data is replaced by a pseudo-random sequence generated\n> > > > + from a PN9 512-bit sequence (typically implemented in hardware with\n> > > > + a linear feedback shift register). The generator should be reset at\n> > > > + the beginning of each frame, and thus each subsequent raw frame with\n> > > > + this test pattern should be exactly the same as the last.\n> > >\n> > > Same question.\n> > >\n> >\n> > IMX219 produces \"PN9\".\n> >\n> > > > + - name: SensorTestPatternModeCustom1\n> > > > + value: 5\n> > > > + description: |\n> > > > + The first custom test pattern. All custom patterns that are\n> > > > + available only on this camera device are at least this numeric\n> > > > + value. All of the custom test patterns will be static (that is the\n> > > > + raw image must not vary from frame to frame).\n> > >\n> > > Could we figure out a better way to implement support for custom test\n> > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for\n> > > new patterns to be defined. Starting at a higher value would be an\n> > > option, but I'd like to find a good way to handle custom values, for all\n> > > controls that have the same issue.\n> > >\n> >\n> > That's a good question. I think we're not so interested in custom\n> > values right now.\n> > So we can drop this now. Is it fine?\n> >\n> >\n> > > > +\n> > > > ...\n> > >\n> > > --\n> > > Regards,\n> > >\n> > > Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 550E4BD224\n\tfor ;\n\tTue, 13 Apr 2021 08:42:20 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id BFB92687FE;\n\tTue, 13 Apr 2021 10:42:19 +0200 (CEST)","from mail-ed1-x534.google.com (mail-ed1-x534.google.com\n\t[IPv6:2a00:1450:4864:20::534])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 809F3687F3\n\tfor ;\n\tTue, 13 Apr 2021 10:42:18 +0200 (CEST)","by mail-ed1-x534.google.com with SMTP id w23so18417070edx.7\n\tfor ;\n\tTue, 13 Apr 2021 01:42:18 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"EH9ioMNL\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=prJGZAVRhm3Vj8F6yqWXXVTo31PCiFUiBxdoRQOL+L0=;\n\tb=EH9ioMNLgNouDzoaSDslkPuUaDA/UP28dw5K2NSXLFZRX4lgOF/NIRmQn1ouiZPJms\n\tIAU1sibkXk9QsaY8of122Avg+vF5dwCl6pYRB0tqqKgVDYcpuP5CTr6hZevnTkvBV4uR\n\tlTGwvV3O24EW2WMxjiubYxyr0PaW5ff23RzvY=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=prJGZAVRhm3Vj8F6yqWXXVTo31PCiFUiBxdoRQOL+L0=;\n\tb=BwV1CvoJH/RyDriKBmhUAGduhiWgttZMYFoHfBwfn0rRmSaC7RoqYIIDNB2pDUo8qO\n\tGwcYBJNQ66uwQ46AJ/A5M8P90x90gAl0wDDdPJC3ROyNr0WIDFcmLsKhFKBBOcsgwCzd\n\tFl4QVTi2ID7+yQb8zocdlSVhai4I3W6Fv8pnWwFxmWBkv4hpvV9wYKymrP0DS58vqaPy\n\twLfd4VI27jSjsub6ND7Nzcope7QoXyhYHCXJMK1Z9+L+JBgqCMt0dKy1744S0zOMug+E\n\t/0yLZz/gu3hJMVN2flEA1wJXZfVVEjA0grxBK0RyJMQrGKizOQEmWAKXV7rXc9K1Rjx2\n\tBKLA==","X-Gm-Message-State":"AOAM530kMcnJIwRFzXS44Mt69If5SzzFabc2DbSOgfzRSx6GESli5QVz\n\tP8IT/ceaWSLVpA7jvp+zCxZuFEG9UPBJnVYMjaBVOA==","X-Google-Smtp-Source":"ABdhPJys/FLLpZuudUNgZVHEeHcnMZJjrPoDOnybGdTRIpspXYRZ1X01s36z3n9TSEjDvCgwW4YvPNiwD5DWDwutBBs=","X-Received":"by 2002:aa7:c80b:: with SMTP id\n\ta11mr31448798edt.325.1618303338123; \n\tTue, 13 Apr 2021 01:42:18 -0700 (PDT)","MIME-Version":"1.0","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>\n\t\n\t\n\t","In-Reply-To":"","From":"Hirokazu Honda ","Date":"Tue, 13 Apr 2021 17:42:07 +0900","Message-ID":"","To":"Laurent Pinchart ,\n\tTomasz Figa ","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":16375,"web_url":"https://patchwork.libcamera.org/comment/16375/","msgid":"","date":"2021-04-20T01:25:29","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Hiro,\n\nOn Tue, Apr 13, 2021 at 05:10:39PM +0900, Hirokazu Honda wrote:\n> On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart wrote:\n> > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> > > The control is used to report available sensor test pattern modes\n> > > and also specify the mode to sensor.\n> > >\n> > > Signed-off-by: Hirokazu Honda \n> > > ---\n> > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> > > 1 file changed, 59 insertions(+)\n> > >\n> > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> > > index b4771f9d..be2f710a 100644\n> > > --- a/src/libcamera/control_ids.yaml\n> > > +++ b/src/libcamera/control_ids.yaml\n> > > @@ -608,4 +608,63 @@ controls:\n> > > detection, additional format conversions etc) count as an additional\n> > > pipeline stage.\n> > >\n> > > + - SensorTestPatternMode:\n> >\n> > Does this need to be limited to the sensor, or can we also produce the\n> > test pattern on the ISP side ? I'm thinking about SoCs that have a test\n> > pattern generator in the inline ISP, in the Bayer domain, just after the\n> > CSI-2 receiver.\n> \n> Shall I just name TestPatternMode?\n\nSounds good.\n\n> > > + type: int32_t\n> > > + draft: true\n> > > + description: |\n> > > + Control to select the sensor test pattern mode. Currently identical to\n> > > + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> > > +\n> > > + Mode of operation for the test pattern mode.\n> > > + enum:\n> > > + - name: SensorTestPatternModeOff\n> > > + value: 0\n> > > + description: |\n> > > + No test pattern mode is used. The camera device returns from the\n> > > + image sensor.\n> > > + - name: SensorTestPatternModeSolidColor\n> > > + value: 1\n> > > + description: |\n> > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> > > + color channel.\n> >\n> > How do we pick the colour ?\n> >\n> > > + - name: SensorTestPatternModeColorBars\n> > > + value: 2\n> > > + description: |\n> > > + All pixel data is replaced with an 8-bar color pattern. The vertical\n> > > + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> > > + magenta, red, blue and black. Each bar should take up 1/8 of the\n> > > + sensor pixel array width. When this is not possible, the bar size\n> > > + should be rounded down to the nearest integer and the pattern can\n> > > + repeat on the right side. Each bar's height must always take up the\n> > > + full sensor pixel array height.\n> > > + - name: SensorTestPatternModeColorBarsFadeToGray\n> > > + value: 3\n> > > + description: |\n> > > + The test pattern is similar to SensorTestPatternModeColorBars,\n> > > + except that each bar should start at its specified color at the top\n> > > + and fade to gray at the bottom. Furthermore each bar is further\n> > > + subdevided into a left and right half. The left half should have a\n> > > + smooth gradient, and the right half should have a quantized\n> > > + gradient. In particular, the right half's should consist of blocks\n> > > + of the same color for 1/16th active sensor pixel array width. The\n> > > + least significant bits in the quantized gradient should be copied\n> > > + from the most significant bits of the smooth gradient. The height of\n> > > + each bar should always be a multiple of 128. When this is not the\n> > > + case, the pattern should repeat at the bottom of the image.\n> >\n> > Do you know what sensor implements this ? I've never seen it before.\n> \n> I think ov13858 produces this as \"Vertical Color Bar Type 2\".\n> IMX219 also produces as \"Grey Color Bars\".\n\nI feel that the lack of standardization in test patterns will be a hard\nto handle issue :-S I'll reply to v2 on this topic.\n\n> > > + - name: SensorTestPatternModePn9\n> > > + value: 4\n> > > + description: |\n> > > + All pixel data is replaced by a pseudo-random sequence generated\n> > > + from a PN9 512-bit sequence (typically implemented in hardware with\n> > > + a linear feedback shift register). The generator should be reset at\n> > > + the beginning of each frame, and thus each subsequent raw frame with\n> > > + this test pattern should be exactly the same as the last.\n> >\n> > Same question.\n> \n> IMX219 produces \"PN9\".\n> \n> > > + - name: SensorTestPatternModeCustom1\n> > > + value: 5\n> > > + description: |\n> > > + The first custom test pattern. All custom patterns that are\n> > > + available only on this camera device are at least this numeric\n> > > + value. All of the custom test patterns will be static (that is the\n> > > + raw image must not vary from frame to frame).\n> >\n> > Could we figure out a better way to implement support for custom test\n> > pattern modes ? Having Custom1 immediately following Pn9 won't allow for\n> > new patterns to be defined. Starting at a higher value would be an\n> > option, but I'd like to find a good way to handle custom values, for all\n> > controls that have the same issue.\n> \n> That's a good question. I think we're not so interested in custom\n> values right now.\n> So we can drop this now. Is it fine?\n\nOK.","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 16FF3BD816\n\tfor ;\n\tTue, 20 Apr 2021 01:25:36 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 39BA968838;\n\tTue, 20 Apr 2021 03:25:35 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id D9463602CA\n\tfor ;\n\tTue, 20 Apr 2021 03:25:33 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 50DC9470;\n\tTue, 20 Apr 2021 03:25:33 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"dlM9Px51\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1618881933;\n\tbh=0m9JCfQBAmI20FBuItVsmu7kwaTU2k9Gd6xx8lM1ils=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=dlM9Px518gA18orG5KISn8TQqFhXwA8AWrurRg/6iUioxKnvIooJUTxkmiWjL35+4\n\t8bF/Q+Dhbx046bKmAO/oAzwHbRIAH9BRbs+FokvqsKOfvViUlwXaPidBmtHFFjAS/W\n\tlStTFSe31oYjQCEGcNR8sQXHe+bbO+/NWXEvIahw=","Date":"Tue, 20 Apr 2021 04:25:29 +0300","From":"Laurent Pinchart ","To":"Hirokazu Honda ","Message-ID":"","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>\n\t\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":16376,"web_url":"https://patchwork.libcamera.org/comment/16376/","msgid":"","date":"2021-04-20T01:27:32","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":2,"url":"https://patchwork.libcamera.org/api/people/2/","name":"Laurent Pinchart","email":"laurent.pinchart@ideasonboard.com"},"content":"Hi Hiro,\n\nOn Tue, Apr 13, 2021 at 05:42:07PM +0900, Hirokazu Honda wrote:\n> On Tue, Apr 13, 2021 at 5:26 PM Hirokazu Honda wrote:\n> > On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda wrote:\n> > > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart wrote:\n> > > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> > > > > The control is used to report available sensor test pattern modes\n> > > > > and also specify the mode to sensor.\n> > > > >\n> > > > > Signed-off-by: Hirokazu Honda \n> > > > > ---\n> > > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> > > > > 1 file changed, 59 insertions(+)\n> > > > >\n> > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> > > > > index b4771f9d..be2f710a 100644\n> > > > > --- a/src/libcamera/control_ids.yaml\n> > > > > +++ b/src/libcamera/control_ids.yaml\n> > > > > @@ -608,4 +608,63 @@ controls:\n> > > > > detection, additional format conversions etc) count as an additional\n> > > > > pipeline stage.\n> > > > >\n> > > > > + - SensorTestPatternMode:\n> > > >\n> > > > Does this need to be limited to the sensor, or can we also produce the\n> > > > test pattern on the ISP side ? I'm thinking about SoCs that have a test\n> > > > pattern generator in the inline ISP, in the Bayer domain, just after the\n> > > > CSI-2 receiver.\n> > >\n> > > Shall I just name TestPatternMode?\n> > >\n> > > > > + type: int32_t\n> > > > > + draft: true\n> > > > > + description: |\n> > > > > + Control to select the sensor test pattern mode. Currently identical to\n> > > > > + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> > > > > +\n> > > > > + Mode of operation for the test pattern mode.\n> > > > > + enum:\n> > > > > + - name: SensorTestPatternModeOff\n> > > > > + value: 0\n> > > > > + description: |\n> > > > > + No test pattern mode is used. The camera device returns from the\n> > > > > + image sensor.\n> > > > > + - name: SensorTestPatternModeSolidColor\n> > > > > + value: 1\n> > > > > + description: |\n> > > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> > > > > + color channel.\n> > > >\n> > > > How do we pick the colour ?\n> >\n> > This definition is based on bayer pattern.\n> > All pixels in a frame of the solid color test pattern are identical,\n> > like all green.\n> > cf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR\n> \n> +Tomasz Figa Please correct me if I'm wrong.\n\nDon't we also need an equivalent to\nhttps://developer.android.com/reference/android/hardware/camera2/CaptureRequest#SENSOR_TEST_PATTERN_DATA\n?\n\n> > > > > + - name: SensorTestPatternModeColorBars\n> > > > > + value: 2\n> > > > > + description: |\n> > > > > + All pixel data is replaced with an 8-bar color pattern. The vertical\n> > > > > + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> > > > > + magenta, red, blue and black. Each bar should take up 1/8 of the\n> > > > > + sensor pixel array width. When this is not possible, the bar size\n> > > > > + should be rounded down to the nearest integer and the pattern can\n> > > > > + repeat on the right side. Each bar's height must always take up the\n> > > > > + full sensor pixel array height.\n> > > > > + - name: SensorTestPatternModeColorBarsFadeToGray\n> > > > > + value: 3\n> > > > > + description: |\n> > > > > + The test pattern is similar to SensorTestPatternModeColorBars,\n> > > > > + except that each bar should start at its specified color at the top\n> > > > > + and fade to gray at the bottom. Furthermore each bar is further\n> > > > > + subdevided into a left and right half. The left half should have a\n> > > > > + smooth gradient, and the right half should have a quantized\n> > > > > + gradient. In particular, the right half's should consist of blocks\n> > > > > + of the same color for 1/16th active sensor pixel array width. The\n> > > > > + least significant bits in the quantized gradient should be copied\n> > > > > + from the most significant bits of the smooth gradient. The height of\n> > > > > + each bar should always be a multiple of 128. When this is not the\n> > > > > + case, the pattern should repeat at the bottom of the image.\n> > > >\n> > > > Do you know what sensor implements this ? I've never seen it before.\n> > >\n> > > I think ov13858 produces this as \"Vertical Color Bar Type 2\".\n> > > IMX219 also produces as \"Grey Color Bars\".\n> > >\n> > > > > + - name: SensorTestPatternModePn9\n> > > > > + value: 4\n> > > > > + description: |\n> > > > > + All pixel data is replaced by a pseudo-random sequence generated\n> > > > > + from a PN9 512-bit sequence (typically implemented in hardware with\n> > > > > + a linear feedback shift register). The generator should be reset at\n> > > > > + the beginning of each frame, and thus each subsequent raw frame with\n> > > > > + this test pattern should be exactly the same as the last.\n> > > >\n> > > > Same question.\n> > >\n> > > IMX219 produces \"PN9\".\n> > >\n> > > > > + - name: SensorTestPatternModeCustom1\n> > > > > + value: 5\n> > > > > + description: |\n> > > > > + The first custom test pattern. All custom patterns that are\n> > > > > + available only on this camera device are at least this numeric\n> > > > > + value. All of the custom test patterns will be static (that is the\n> > > > > + raw image must not vary from frame to frame).\n> > > >\n> > > > Could we figure out a better way to implement support for custom test\n> > > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for\n> > > > new patterns to be defined. Starting at a higher value would be an\n> > > > option, but I'd like to find a good way to handle custom values, for all\n> > > > controls that have the same issue.\n> > >\n> > > That's a good question. I think we're not so interested in custom\n> > > values right now.\n> > > So we can drop this now. Is it fine?","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id CE50DBD814\n\tfor ;\n\tTue, 20 Apr 2021 01:27:37 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 39CBF6883D;\n\tTue, 20 Apr 2021 03:27:37 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 56873602CA\n\tfor ;\n\tTue, 20 Apr 2021 03:27:36 +0200 (CEST)","from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi\n\t[62.78.145.57])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id C5444470;\n\tTue, 20 Apr 2021 03:27:35 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"BFFjHpfc\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1618882056;\n\tbh=mPb6GMlgm00DuYz0b7Ty56z3wr86D6/E3SqeR9j/ePk=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=BFFjHpfcMGOxF3JGwigxvi+mzNuBzvOOlYkT4uJtKVTkkBgCkf6cUuaam98HcS/ZF\n\tLXsK/DZAGYJ4eZIWceB0pTq3gMDMY7n7S900NExEWTkfKiGOmXq5oQ4b40Ktwp9ehL\n\tyfs+m+T6bDL4hZKE28ym3LH6ye1X14ByCGbbDaks=","Date":"Tue, 20 Apr 2021 04:27:32 +0300","From":"Laurent Pinchart ","To":"Hirokazu Honda ","Message-ID":"","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>\n\t\n\t\n\t\n\t","MIME-Version":"1.0","Content-Disposition":"inline","In-Reply-To":"","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":16423,"web_url":"https://patchwork.libcamera.org/comment/16423/","msgid":"","date":"2021-04-21T04:16:13","subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","submitter":{"id":63,"url":"https://patchwork.libcamera.org/api/people/63/","name":"Hirokazu Honda","email":"hiroh@chromium.org"},"content":"On Tue, Apr 20, 2021 at 10:27 AM Laurent Pinchart\n wrote:\n>\n> Hi Hiro,\n>\n> On Tue, Apr 13, 2021 at 05:42:07PM +0900, Hirokazu Honda wrote:\n> > On Tue, Apr 13, 2021 at 5:26 PM Hirokazu Honda wrote:\n> > > On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda wrote:\n> > > > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart wrote:\n> > > > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote:\n> > > > > > The control is used to report available sensor test pattern modes\n> > > > > > and also specify the mode to sensor.\n> > > > > >\n> > > > > > Signed-off-by: Hirokazu Honda \n> > > > > > ---\n> > > > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++\n> > > > > > 1 file changed, 59 insertions(+)\n> > > > > >\n> > > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml\n> > > > > > index b4771f9d..be2f710a 100644\n> > > > > > --- a/src/libcamera/control_ids.yaml\n> > > > > > +++ b/src/libcamera/control_ids.yaml\n> > > > > > @@ -608,4 +608,63 @@ controls:\n> > > > > > detection, additional format conversions etc) count as an additional\n> > > > > > pipeline stage.\n> > > > > >\n> > > > > > + - SensorTestPatternMode:\n> > > > >\n> > > > > Does this need to be limited to the sensor, or can we also produce the\n> > > > > test pattern on the ISP side ? I'm thinking about SoCs that have a test\n> > > > > pattern generator in the inline ISP, in the Bayer domain, just after the\n> > > > > CSI-2 receiver.\n> > > >\n> > > > Shall I just name TestPatternMode?\n> > > >\n> > > > > > + type: int32_t\n> > > > > > + draft: true\n> > > > > > + description: |\n> > > > > > + Control to select the sensor test pattern mode. Currently identical to\n> > > > > > + ANDROID_SENSOR_TEST_PATTERN_MODE.\n> > > > > > +\n> > > > > > + Mode of operation for the test pattern mode.\n> > > > > > + enum:\n> > > > > > + - name: SensorTestPatternModeOff\n> > > > > > + value: 0\n> > > > > > + description: |\n> > > > > > + No test pattern mode is used. The camera device returns from the\n> > > > > > + image sensor.\n> > > > > > + - name: SensorTestPatternModeSolidColor\n> > > > > > + value: 1\n> > > > > > + description: |\n> > > > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective\n> > > > > > + color channel.\n> > > > >\n> > > > > How do we pick the colour ?\n> > >\n> > > This definition is based on bayer pattern.\n> > > All pixels in a frame of the solid color test pattern are identical,\n> > > like all green.\n> > > cf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR\n> >\n> > +Tomasz Figa Please correct me if I'm wrong.\n>\n> Don't we also need an equivalent to\n> https://developer.android.com/reference/android/hardware/camera2/CaptureRequest#SENSOR_TEST_PATTERN_DATA\n> ?\n>\n\nThanks for catching. Yes, you're right. I think we should add it.\nI will do it in another patch series.\n-Hiro\n\n> > > > > > + - name: SensorTestPatternModeColorBars\n> > > > > > + value: 2\n> > > > > > + description: |\n> > > > > > + All pixel data is replaced with an 8-bar color pattern. The vertical\n> > > > > > + bars (left-to-right) are as follows; white, yellow, cyan, green,\n> > > > > > + magenta, red, blue and black. Each bar should take up 1/8 of the\n> > > > > > + sensor pixel array width. When this is not possible, the bar size\n> > > > > > + should be rounded down to the nearest integer and the pattern can\n> > > > > > + repeat on the right side. Each bar's height must always take up the\n> > > > > > + full sensor pixel array height.\n> > > > > > + - name: SensorTestPatternModeColorBarsFadeToGray\n> > > > > > + value: 3\n> > > > > > + description: |\n> > > > > > + The test pattern is similar to SensorTestPatternModeColorBars,\n> > > > > > + except that each bar should start at its specified color at the top\n> > > > > > + and fade to gray at the bottom. Furthermore each bar is further\n> > > > > > + subdevided into a left and right half. The left half should have a\n> > > > > > + smooth gradient, and the right half should have a quantized\n> > > > > > + gradient. In particular, the right half's should consist of blocks\n> > > > > > + of the same color for 1/16th active sensor pixel array width. The\n> > > > > > + least significant bits in the quantized gradient should be copied\n> > > > > > + from the most significant bits of the smooth gradient. The height of\n> > > > > > + each bar should always be a multiple of 128. When this is not the\n> > > > > > + case, the pattern should repeat at the bottom of the image.\n> > > > >\n> > > > > Do you know what sensor implements this ? I've never seen it before.\n> > > >\n> > > > I think ov13858 produces this as \"Vertical Color Bar Type 2\".\n> > > > IMX219 also produces as \"Grey Color Bars\".\n> > > >\n> > > > > > + - name: SensorTestPatternModePn9\n> > > > > > + value: 4\n> > > > > > + description: |\n> > > > > > + All pixel data is replaced by a pseudo-random sequence generated\n> > > > > > + from a PN9 512-bit sequence (typically implemented in hardware with\n> > > > > > + a linear feedback shift register). The generator should be reset at\n> > > > > > + the beginning of each frame, and thus each subsequent raw frame with\n> > > > > > + this test pattern should be exactly the same as the last.\n> > > > >\n> > > > > Same question.\n> > > >\n> > > > IMX219 produces \"PN9\".\n> > > >\n> > > > > > + - name: SensorTestPatternModeCustom1\n> > > > > > + value: 5\n> > > > > > + description: |\n> > > > > > + The first custom test pattern. All custom patterns that are\n> > > > > > + available only on this camera device are at least this numeric\n> > > > > > + value. All of the custom test patterns will be static (that is the\n> > > > > > + raw image must not vary from frame to frame).\n> > > > >\n> > > > > Could we figure out a better way to implement support for custom test\n> > > > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for\n> > > > > new patterns to be defined. Starting at a higher value would be an\n> > > > > option, but I'd like to find a good way to handle custom values, for all\n> > > > > controls that have the same issue.\n> > > >\n> > > > That's a good question. I think we're not so interested in custom\n> > > > values right now.\n> > > > So we can drop this now. Is it fine?\n>\n> --\n> Regards,\n>\n> Laurent Pinchart","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 9B684BDB15\n\tfor ;\n\tWed, 21 Apr 2021 04:16:27 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id E9DEA6883E;\n\tWed, 21 Apr 2021 06:16:26 +0200 (CEST)","from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com\n\t[IPv6:2a00:1450:4864:20::62c])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id A0224602C3\n\tfor ;\n\tWed, 21 Apr 2021 06:16:24 +0200 (CEST)","by mail-ej1-x62c.google.com with SMTP id n2so61450737ejy.7\n\tfor ;\n\tTue, 20 Apr 2021 21:16:24 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=chromium.org header.i=@chromium.org\n\theader.b=\"ckXzKGXE\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org;\n\ts=google; \n\th=mime-version:references:in-reply-to:from:date:message-id:subject:to\n\t:cc; bh=3JhKjKMxDne+JMMqyjmSQ6HlvHDZhkoZpH/ogh1o9tA=;\n\tb=ckXzKGXEUZoQeOKXqVJj0KsxueVFfZQsTNDmJYnIhaeG4ty9RHQ0pfVIFeyePs1kky\n\tu1ic/XYnu7hYsZKV8Ovuh8rNUmuSu6sZJOm9XM5oCveyKbQjDoQKVLdYa+y1j0s+yfXd\n\tIZoa1bEoxG79TkhvfEK5Xb8Lsg1l/khGV12h8=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:references:in-reply-to:from:date\n\t:message-id:subject:to:cc;\n\tbh=3JhKjKMxDne+JMMqyjmSQ6HlvHDZhkoZpH/ogh1o9tA=;\n\tb=qwFAFPWiQp2pg/zt0K3W6PY+5xGu+1aD3nYGYJmoSUfL3QpBJR8BWh/H1At3DOsLDv\n\t0RV5LRJQt8s+nf2UobH3CFqVZm2xG5wzeREKLWli8+WG/FU2sbULASafIlMd918FzwFK\n\tTkYAq+5254I/44SrJgxRZF1svbOtnVc5m4joGxYnoKU3jIPWy14sE3C3NLRjPeG64/FH\n\t8s5Wy9Fbcxv3DQ2gzKpDP8NdHb24Ti5GyEKi9bOYvLZKK2nvFv9/jAKC7zVuFHfsOegD\n\tPdtZXD1ACxTw+cJnbmNumwNhJaN4ruqDjcGfaLspD/5VcWuIwgXgSnxp+hmUJWXf+wzY\n\t4Wbg==","X-Gm-Message-State":"AOAM530SCHLo5YCKZvuV26VuIkit8FqKp+yvW2MMacSqOyv0gEFmLSkE\n\tBHwA3WE3jXKXWri3ai8SbeGolvWhICCk4BnmpB+RtQ==","X-Google-Smtp-Source":"ABdhPJx39PwEx1km54ki18swjobJMB1sc9WGB2NxSKD4Dy/X2ktxwc9d1HhNuz7oADSmmcjylJw6NS+ZNvNC/IPExew=","X-Received":"by 2002:a17:906:fcc4:: with SMTP id\n\tqx4mr30108933ejb.42.1618978584182; \n\tTue, 20 Apr 2021 21:16:24 -0700 (PDT)","MIME-Version":"1.0","References":"<20210409043208.1823330-1-hiroh@chromium.org>\n\t<20210409043208.1823330-2-hiroh@chromium.org>\n\t\n\t\n\t\n\t\n\t","In-Reply-To":"","From":"Hirokazu Honda ","Date":"Wed, 21 Apr 2021 13:16:13 +0900","Message-ID":"","To":"Laurent Pinchart ","Subject":"Re: [libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add\n\tsensor test pattern mode","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"libcamera devel ","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]