| Message ID | 20210409043208.1823330-2-hiroh@chromium.org |
|---|---|
| State | RFC |
| Headers | show |
| Series |
|
| Related | show |
Hi Hiro, On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > The control is used to report available sensor test pattern modes > and also specify the mode to sensor. > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > --- > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > 1 file changed, 59 insertions(+) > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > index b4771f9d..be2f710a 100644 > --- a/src/libcamera/control_ids.yaml > +++ b/src/libcamera/control_ids.yaml > @@ -608,4 +608,63 @@ controls: > detection, additional format conversions etc) count as an additional > pipeline stage. > > + - SensorTestPatternMode: > + type: int32_t > + draft: true > + description: | > + Control to select the sensor test pattern mode. Currently identical to > + ANDROID_SENSOR_TEST_PATTERN_MODE. > + > + Mode of operation for the test pattern mode. You can drop this line, but it's ok > + enum: > + - name: SensorTestPatternModeOff > + value: 0 > + description: | > + No test pattern mode is used. The camera device returns from the > + image sensor. > + - name: SensorTestPatternModeSolidColor > + value: 1 > + description: | > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > + color channel. > + - name: SensorTestPatternModeColorBars > + value: 2 > + description: | > + All pixel data is replaced with an 8-bar color pattern. The vertical > + bars (left-to-right) are as follows; white, yellow, cyan, green, > + magenta, red, blue and black. Each bar should take up 1/8 of the > + sensor pixel array width. When this is not possible, the bar size > + should be rounded down to the nearest integer and the pattern can > + repeat on the right side. Each bar's height must always take up the > + full sensor pixel array height. > + - name: SensorTestPatternModeColorBarsFadeToGray > + value: 3 > + description: | > + The test pattern is similar to SensorTestPatternModeColorBars, > + except that each bar should start at its specified color at the top > + and fade to gray at the bottom. Furthermore each bar is further > + subdevided into a left and right half. The left half should have a > + smooth gradient, and the right half should have a quantized > + gradient. In particular, the right half's should consist of blocks > + of the same color for 1/16th active sensor pixel array width. The > + least significant bits in the quantized gradient should be copied > + from the most significant bits of the smooth gradient. The height of > + each bar should always be a multiple of 128. When this is not the > + case, the pattern should repeat at the bottom of the image. > + - name: SensorTestPatternModePn9 > + value: 4 > + description: | > + All pixel data is replaced by a pseudo-random sequence generated > + from a PN9 512-bit sequence (typically implemented in hardware with > + a linear feedback shift register). The generator should be reset at > + the beginning of each frame, and thus each subsequent raw frame with > + this test pattern should be exactly the same as the last. > + - name: SensorTestPatternModeCustom1 > + value: 5 > + description: | > + The first custom test pattern. All custom patterns that are > + available only on this camera device are at least this numeric > + value. All of the custom test patterns will be static (that is the > + raw image must not vary from frame to frame). > + Thanks for the details descriptions. They're not strictly necessary as we explicitly refer to ANDROID_SENSOR_TEST_PATTERN_MODE in the control definition, but doesn't hurt to have them here. Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Thanks j > ... > -- > 2.31.1.295.g9ea45b61b8-goog > > _______________________________________________ > libcamera-devel mailing list > libcamera-devel@lists.libcamera.org > https://lists.libcamera.org/listinfo/libcamera-devel
Hi Hiro, Thank you for the patch. On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > The control is used to report available sensor test pattern modes > and also specify the mode to sensor. > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > --- > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > 1 file changed, 59 insertions(+) > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > index b4771f9d..be2f710a 100644 > --- a/src/libcamera/control_ids.yaml > +++ b/src/libcamera/control_ids.yaml > @@ -608,4 +608,63 @@ controls: > detection, additional format conversions etc) count as an additional > pipeline stage. > > + - SensorTestPatternMode: Does this need to be limited to the sensor, or can we also produce the test pattern on the ISP side ? I'm thinking about SoCs that have a test pattern generator in the inline ISP, in the Bayer domain, just after the CSI-2 receiver. > + type: int32_t > + draft: true > + description: | > + Control to select the sensor test pattern mode. Currently identical to > + ANDROID_SENSOR_TEST_PATTERN_MODE. > + > + Mode of operation for the test pattern mode. > + enum: > + - name: SensorTestPatternModeOff > + value: 0 > + description: | > + No test pattern mode is used. The camera device returns from the > + image sensor. > + - name: SensorTestPatternModeSolidColor > + value: 1 > + description: | > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > + color channel. How do we pick the colour ? > + - name: SensorTestPatternModeColorBars > + value: 2 > + description: | > + All pixel data is replaced with an 8-bar color pattern. The vertical > + bars (left-to-right) are as follows; white, yellow, cyan, green, > + magenta, red, blue and black. Each bar should take up 1/8 of the > + sensor pixel array width. When this is not possible, the bar size > + should be rounded down to the nearest integer and the pattern can > + repeat on the right side. Each bar's height must always take up the > + full sensor pixel array height. > + - name: SensorTestPatternModeColorBarsFadeToGray > + value: 3 > + description: | > + The test pattern is similar to SensorTestPatternModeColorBars, > + except that each bar should start at its specified color at the top > + and fade to gray at the bottom. Furthermore each bar is further > + subdevided into a left and right half. The left half should have a > + smooth gradient, and the right half should have a quantized > + gradient. In particular, the right half's should consist of blocks > + of the same color for 1/16th active sensor pixel array width. The > + least significant bits in the quantized gradient should be copied > + from the most significant bits of the smooth gradient. The height of > + each bar should always be a multiple of 128. When this is not the > + case, the pattern should repeat at the bottom of the image. Do you know what sensor implements this ? I've never seen it before. > + - name: SensorTestPatternModePn9 > + value: 4 > + description: | > + All pixel data is replaced by a pseudo-random sequence generated > + from a PN9 512-bit sequence (typically implemented in hardware with > + a linear feedback shift register). The generator should be reset at > + the beginning of each frame, and thus each subsequent raw frame with > + this test pattern should be exactly the same as the last. Same question. > + - name: SensorTestPatternModeCustom1 > + value: 5 > + description: | > + The first custom test pattern. All custom patterns that are > + available only on this camera device are at least this numeric > + value. All of the custom test patterns will be static (that is the > + raw image must not vary from frame to frame). Could we figure out a better way to implement support for custom test pattern modes ? Having Custom1 immediately following Pn9 won't allow for new patterns to be defined. Starting at a higher value would be an option, but I'd like to find a good way to handle custom values, for all controls that have the same issue. > + > ...
On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hiro, > > Thank you for the patch. > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > > The control is used to report available sensor test pattern modes > > and also specify the mode to sensor. > > > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > > --- > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > > 1 file changed, 59 insertions(+) > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > > index b4771f9d..be2f710a 100644 > > --- a/src/libcamera/control_ids.yaml > > +++ b/src/libcamera/control_ids.yaml > > @@ -608,4 +608,63 @@ controls: > > detection, additional format conversions etc) count as an additional > > pipeline stage. > > > > + - SensorTestPatternMode: > > Does this need to be limited to the sensor, or can we also produce the > test pattern on the ISP side ? I'm thinking about SoCs that have a test > pattern generator in the inline ISP, in the Bayer domain, just after the > CSI-2 receiver. > Shall I just name TestPatternMode? > > + type: int32_t > > + draft: true > > + description: | > > + Control to select the sensor test pattern mode. Currently identical to > > + ANDROID_SENSOR_TEST_PATTERN_MODE. > > + > > + Mode of operation for the test pattern mode. > > + enum: > > + - name: SensorTestPatternModeOff > > + value: 0 > > + description: | > > + No test pattern mode is used. The camera device returns from the > > + image sensor. > > + - name: SensorTestPatternModeSolidColor > > + value: 1 > > + description: | > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > > + color channel. > > How do we pick the colour ? > > > + - name: SensorTestPatternModeColorBars > > + value: 2 > > + description: | > > + All pixel data is replaced with an 8-bar color pattern. The vertical > > + bars (left-to-right) are as follows; white, yellow, cyan, green, > > + magenta, red, blue and black. Each bar should take up 1/8 of the > > + sensor pixel array width. When this is not possible, the bar size > > + should be rounded down to the nearest integer and the pattern can > > + repeat on the right side. Each bar's height must always take up the > > + full sensor pixel array height. > > + - name: SensorTestPatternModeColorBarsFadeToGray > > + value: 3 > > + description: | > > + The test pattern is similar to SensorTestPatternModeColorBars, > > + except that each bar should start at its specified color at the top > > + and fade to gray at the bottom. Furthermore each bar is further > > + subdevided into a left and right half. The left half should have a > > + smooth gradient, and the right half should have a quantized > > + gradient. In particular, the right half's should consist of blocks > > + of the same color for 1/16th active sensor pixel array width. The > > + least significant bits in the quantized gradient should be copied > > + from the most significant bits of the smooth gradient. The height of > > + each bar should always be a multiple of 128. When this is not the > > + case, the pattern should repeat at the bottom of the image. > > Do you know what sensor implements this ? I've never seen it before. > I think ov13858 produces this as "Vertical Color Bar Type 2". IMX219 also produces as "Grey Color Bars". > > + - name: SensorTestPatternModePn9 > > + value: 4 > > + description: | > > + All pixel data is replaced by a pseudo-random sequence generated > > + from a PN9 512-bit sequence (typically implemented in hardware with > > + a linear feedback shift register). The generator should be reset at > > + the beginning of each frame, and thus each subsequent raw frame with > > + this test pattern should be exactly the same as the last. > > Same question. > IMX219 produces "PN9". > > + - name: SensorTestPatternModeCustom1 > > + value: 5 > > + description: | > > + The first custom test pattern. All custom patterns that are > > + available only on this camera device are at least this numeric > > + value. All of the custom test patterns will be static (that is the > > + raw image must not vary from frame to frame). > > Could we figure out a better way to implement support for custom test > pattern modes ? Having Custom1 immediately following Pn9 won't allow for > new patterns to be defined. Starting at a higher value would be an > option, but I'd like to find a good way to handle custom values, for all > controls that have the same issue. > That's a good question. I think we're not so interested in custom values right now. So we can drop this now. Is it fine? > > + > > ... > > -- > Regards, > > Laurent Pinchart
On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda <hiroh@chromium.org> wrote: > > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: > > > > Hi Hiro, > > > > Thank you for the patch. > > > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > > > The control is used to report available sensor test pattern modes > > > and also specify the mode to sensor. > > > > > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > > > --- > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > > > 1 file changed, 59 insertions(+) > > > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > > > index b4771f9d..be2f710a 100644 > > > --- a/src/libcamera/control_ids.yaml > > > +++ b/src/libcamera/control_ids.yaml > > > @@ -608,4 +608,63 @@ controls: > > > detection, additional format conversions etc) count as an additional > > > pipeline stage. > > > > > > + - SensorTestPatternMode: > > > > Does this need to be limited to the sensor, or can we also produce the > > test pattern on the ISP side ? I'm thinking about SoCs that have a test > > pattern generator in the inline ISP, in the Bayer domain, just after the > > CSI-2 receiver. > > > > Shall I just name TestPatternMode? > > > > + type: int32_t > > > + draft: true > > > + description: | > > > + Control to select the sensor test pattern mode. Currently identical to > > > + ANDROID_SENSOR_TEST_PATTERN_MODE. > > > + > > > + Mode of operation for the test pattern mode. > > > + enum: > > > + - name: SensorTestPatternModeOff > > > + value: 0 > > > + description: | > > > + No test pattern mode is used. The camera device returns from the > > > + image sensor. > > > + - name: SensorTestPatternModeSolidColor > > > + value: 1 > > > + description: | > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > > > + color channel. > > > > How do we pick the colour ? > > This definition is based on bayer pattern. All pixels in a frame of the solid color test pattern are identical, like all green. cf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR > > > + - name: SensorTestPatternModeColorBars > > > + value: 2 > > > + description: | > > > + All pixel data is replaced with an 8-bar color pattern. The vertical > > > + bars (left-to-right) are as follows; white, yellow, cyan, green, > > > + magenta, red, blue and black. Each bar should take up 1/8 of the > > > + sensor pixel array width. When this is not possible, the bar size > > > + should be rounded down to the nearest integer and the pattern can > > > + repeat on the right side. Each bar's height must always take up the > > > + full sensor pixel array height. > > > + - name: SensorTestPatternModeColorBarsFadeToGray > > > + value: 3 > > > + description: | > > > + The test pattern is similar to SensorTestPatternModeColorBars, > > > + except that each bar should start at its specified color at the top > > > + and fade to gray at the bottom. Furthermore each bar is further > > > + subdevided into a left and right half. The left half should have a > > > + smooth gradient, and the right half should have a quantized > > > + gradient. In particular, the right half's should consist of blocks > > > + of the same color for 1/16th active sensor pixel array width. The > > > + least significant bits in the quantized gradient should be copied > > > + from the most significant bits of the smooth gradient. The height of > > > + each bar should always be a multiple of 128. When this is not the > > > + case, the pattern should repeat at the bottom of the image. > > > > Do you know what sensor implements this ? I've never seen it before. > > > > I think ov13858 produces this as "Vertical Color Bar Type 2". > IMX219 also produces as "Grey Color Bars". > > > > + - name: SensorTestPatternModePn9 > > > + value: 4 > > > + description: | > > > + All pixel data is replaced by a pseudo-random sequence generated > > > + from a PN9 512-bit sequence (typically implemented in hardware with > > > + a linear feedback shift register). The generator should be reset at > > > + the beginning of each frame, and thus each subsequent raw frame with > > > + this test pattern should be exactly the same as the last. > > > > Same question. > > > > IMX219 produces "PN9". > > > > + - name: SensorTestPatternModeCustom1 > > > + value: 5 > > > + description: | > > > + The first custom test pattern. All custom patterns that are > > > + available only on this camera device are at least this numeric > > > + value. All of the custom test patterns will be static (that is the > > > + raw image must not vary from frame to frame). > > > > Could we figure out a better way to implement support for custom test > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for > > new patterns to be defined. Starting at a higher value would be an > > option, but I'd like to find a good way to handle custom values, for all > > controls that have the same issue. > > > > That's a good question. I think we're not so interested in custom > values right now. > So we can drop this now. Is it fine? > > > > > + > > > ... > > > > -- > > Regards, > > > > Laurent Pinchart
On Tue, Apr 13, 2021 at 5:26 PM Hirokazu Honda <hiroh@chromium.org> wrote: > > On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda <hiroh@chromium.org> wrote: > > > > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart > > <laurent.pinchart@ideasonboard.com> wrote: > > > > > > Hi Hiro, > > > > > > Thank you for the patch. > > > > > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > > > > The control is used to report available sensor test pattern modes > > > > and also specify the mode to sensor. > > > > > > > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > > > > --- > > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 59 insertions(+) > > > > > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > > > > index b4771f9d..be2f710a 100644 > > > > --- a/src/libcamera/control_ids.yaml > > > > +++ b/src/libcamera/control_ids.yaml > > > > @@ -608,4 +608,63 @@ controls: > > > > detection, additional format conversions etc) count as an additional > > > > pipeline stage. > > > > > > > > + - SensorTestPatternMode: > > > > > > Does this need to be limited to the sensor, or can we also produce the > > > test pattern on the ISP side ? I'm thinking about SoCs that have a test > > > pattern generator in the inline ISP, in the Bayer domain, just after the > > > CSI-2 receiver. > > > > > > > Shall I just name TestPatternMode? > > > > > > + type: int32_t > > > > + draft: true > > > > + description: | > > > > + Control to select the sensor test pattern mode. Currently identical to > > > > + ANDROID_SENSOR_TEST_PATTERN_MODE. > > > > + > > > > + Mode of operation for the test pattern mode. > > > > + enum: > > > > + - name: SensorTestPatternModeOff > > > > + value: 0 > > > > + description: | > > > > + No test pattern mode is used. The camera device returns from the > > > > + image sensor. > > > > + - name: SensorTestPatternModeSolidColor > > > > + value: 1 > > > > + description: | > > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > > > > + color channel. > > > > > > How do we pick the colour ? > > > > > This definition is based on bayer pattern. > All pixels in a frame of the solid color test pattern are identical, > like all green. > cf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR > +Tomasz Figa Please correct me if I'm wrong. > > > > + - name: SensorTestPatternModeColorBars > > > > + value: 2 > > > > + description: | > > > > + All pixel data is replaced with an 8-bar color pattern. The vertical > > > > + bars (left-to-right) are as follows; white, yellow, cyan, green, > > > > + magenta, red, blue and black. Each bar should take up 1/8 of the > > > > + sensor pixel array width. When this is not possible, the bar size > > > > + should be rounded down to the nearest integer and the pattern can > > > > + repeat on the right side. Each bar's height must always take up the > > > > + full sensor pixel array height. > > > > + - name: SensorTestPatternModeColorBarsFadeToGray > > > > + value: 3 > > > > + description: | > > > > + The test pattern is similar to SensorTestPatternModeColorBars, > > > > + except that each bar should start at its specified color at the top > > > > + and fade to gray at the bottom. Furthermore each bar is further > > > > + subdevided into a left and right half. The left half should have a > > > > + smooth gradient, and the right half should have a quantized > > > > + gradient. In particular, the right half's should consist of blocks > > > > + of the same color for 1/16th active sensor pixel array width. The > > > > + least significant bits in the quantized gradient should be copied > > > > + from the most significant bits of the smooth gradient. The height of > > > > + each bar should always be a multiple of 128. When this is not the > > > > + case, the pattern should repeat at the bottom of the image. > > > > > > Do you know what sensor implements this ? I've never seen it before. > > > > > > > I think ov13858 produces this as "Vertical Color Bar Type 2". > > IMX219 also produces as "Grey Color Bars". > > > > > > + - name: SensorTestPatternModePn9 > > > > + value: 4 > > > > + description: | > > > > + All pixel data is replaced by a pseudo-random sequence generated > > > > + from a PN9 512-bit sequence (typically implemented in hardware with > > > > + a linear feedback shift register). The generator should be reset at > > > > + the beginning of each frame, and thus each subsequent raw frame with > > > > + this test pattern should be exactly the same as the last. > > > > > > Same question. > > > > > > > IMX219 produces "PN9". > > > > > > + - name: SensorTestPatternModeCustom1 > > > > + value: 5 > > > > + description: | > > > > + The first custom test pattern. All custom patterns that are > > > > + available only on this camera device are at least this numeric > > > > + value. All of the custom test patterns will be static (that is the > > > > + raw image must not vary from frame to frame). > > > > > > Could we figure out a better way to implement support for custom test > > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for > > > new patterns to be defined. Starting at a higher value would be an > > > option, but I'd like to find a good way to handle custom values, for all > > > controls that have the same issue. > > > > > > > That's a good question. I think we're not so interested in custom > > values right now. > > So we can drop this now. Is it fine? > > > > > > > > + > > > > ... > > > > > > -- > > > Regards, > > > > > > Laurent Pinchart
Hi Hiro, On Tue, Apr 13, 2021 at 05:10:39PM +0900, Hirokazu Honda wrote: > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart wrote: > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > > > The control is used to report available sensor test pattern modes > > > and also specify the mode to sensor. > > > > > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > > > --- > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > > > 1 file changed, 59 insertions(+) > > > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > > > index b4771f9d..be2f710a 100644 > > > --- a/src/libcamera/control_ids.yaml > > > +++ b/src/libcamera/control_ids.yaml > > > @@ -608,4 +608,63 @@ controls: > > > detection, additional format conversions etc) count as an additional > > > pipeline stage. > > > > > > + - SensorTestPatternMode: > > > > Does this need to be limited to the sensor, or can we also produce the > > test pattern on the ISP side ? I'm thinking about SoCs that have a test > > pattern generator in the inline ISP, in the Bayer domain, just after the > > CSI-2 receiver. > > Shall I just name TestPatternMode? Sounds good. > > > + type: int32_t > > > + draft: true > > > + description: | > > > + Control to select the sensor test pattern mode. Currently identical to > > > + ANDROID_SENSOR_TEST_PATTERN_MODE. > > > + > > > + Mode of operation for the test pattern mode. > > > + enum: > > > + - name: SensorTestPatternModeOff > > > + value: 0 > > > + description: | > > > + No test pattern mode is used. The camera device returns from the > > > + image sensor. > > > + - name: SensorTestPatternModeSolidColor > > > + value: 1 > > > + description: | > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > > > + color channel. > > > > How do we pick the colour ? > > > > > + - name: SensorTestPatternModeColorBars > > > + value: 2 > > > + description: | > > > + All pixel data is replaced with an 8-bar color pattern. The vertical > > > + bars (left-to-right) are as follows; white, yellow, cyan, green, > > > + magenta, red, blue and black. Each bar should take up 1/8 of the > > > + sensor pixel array width. When this is not possible, the bar size > > > + should be rounded down to the nearest integer and the pattern can > > > + repeat on the right side. Each bar's height must always take up the > > > + full sensor pixel array height. > > > + - name: SensorTestPatternModeColorBarsFadeToGray > > > + value: 3 > > > + description: | > > > + The test pattern is similar to SensorTestPatternModeColorBars, > > > + except that each bar should start at its specified color at the top > > > + and fade to gray at the bottom. Furthermore each bar is further > > > + subdevided into a left and right half. The left half should have a > > > + smooth gradient, and the right half should have a quantized > > > + gradient. In particular, the right half's should consist of blocks > > > + of the same color for 1/16th active sensor pixel array width. The > > > + least significant bits in the quantized gradient should be copied > > > + from the most significant bits of the smooth gradient. The height of > > > + each bar should always be a multiple of 128. When this is not the > > > + case, the pattern should repeat at the bottom of the image. > > > > Do you know what sensor implements this ? I've never seen it before. > > I think ov13858 produces this as "Vertical Color Bar Type 2". > IMX219 also produces as "Grey Color Bars". I feel that the lack of standardization in test patterns will be a hard to handle issue :-S I'll reply to v2 on this topic. > > > + - name: SensorTestPatternModePn9 > > > + value: 4 > > > + description: | > > > + All pixel data is replaced by a pseudo-random sequence generated > > > + from a PN9 512-bit sequence (typically implemented in hardware with > > > + a linear feedback shift register). The generator should be reset at > > > + the beginning of each frame, and thus each subsequent raw frame with > > > + this test pattern should be exactly the same as the last. > > > > Same question. > > IMX219 produces "PN9". > > > > + - name: SensorTestPatternModeCustom1 > > > + value: 5 > > > + description: | > > > + The first custom test pattern. All custom patterns that are > > > + available only on this camera device are at least this numeric > > > + value. All of the custom test patterns will be static (that is the > > > + raw image must not vary from frame to frame). > > > > Could we figure out a better way to implement support for custom test > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for > > new patterns to be defined. Starting at a higher value would be an > > option, but I'd like to find a good way to handle custom values, for all > > controls that have the same issue. > > That's a good question. I think we're not so interested in custom > values right now. > So we can drop this now. Is it fine? OK.
Hi Hiro, On Tue, Apr 13, 2021 at 05:42:07PM +0900, Hirokazu Honda wrote: > On Tue, Apr 13, 2021 at 5:26 PM Hirokazu Honda wrote: > > On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda wrote: > > > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart wrote: > > > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > > > > > The control is used to report available sensor test pattern modes > > > > > and also specify the mode to sensor. > > > > > > > > > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > > > > > --- > > > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > > > > > 1 file changed, 59 insertions(+) > > > > > > > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > > > > > index b4771f9d..be2f710a 100644 > > > > > --- a/src/libcamera/control_ids.yaml > > > > > +++ b/src/libcamera/control_ids.yaml > > > > > @@ -608,4 +608,63 @@ controls: > > > > > detection, additional format conversions etc) count as an additional > > > > > pipeline stage. > > > > > > > > > > + - SensorTestPatternMode: > > > > > > > > Does this need to be limited to the sensor, or can we also produce the > > > > test pattern on the ISP side ? I'm thinking about SoCs that have a test > > > > pattern generator in the inline ISP, in the Bayer domain, just after the > > > > CSI-2 receiver. > > > > > > Shall I just name TestPatternMode? > > > > > > > > + type: int32_t > > > > > + draft: true > > > > > + description: | > > > > > + Control to select the sensor test pattern mode. Currently identical to > > > > > + ANDROID_SENSOR_TEST_PATTERN_MODE. > > > > > + > > > > > + Mode of operation for the test pattern mode. > > > > > + enum: > > > > > + - name: SensorTestPatternModeOff > > > > > + value: 0 > > > > > + description: | > > > > > + No test pattern mode is used. The camera device returns from the > > > > > + image sensor. > > > > > + - name: SensorTestPatternModeSolidColor > > > > > + value: 1 > > > > > + description: | > > > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > > > > > + color channel. > > > > > > > > How do we pick the colour ? > > > > This definition is based on bayer pattern. > > All pixels in a frame of the solid color test pattern are identical, > > like all green. > > cf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR > > +Tomasz Figa Please correct me if I'm wrong. Don't we also need an equivalent to https://developer.android.com/reference/android/hardware/camera2/CaptureRequest#SENSOR_TEST_PATTERN_DATA ? > > > > > + - name: SensorTestPatternModeColorBars > > > > > + value: 2 > > > > > + description: | > > > > > + All pixel data is replaced with an 8-bar color pattern. The vertical > > > > > + bars (left-to-right) are as follows; white, yellow, cyan, green, > > > > > + magenta, red, blue and black. Each bar should take up 1/8 of the > > > > > + sensor pixel array width. When this is not possible, the bar size > > > > > + should be rounded down to the nearest integer and the pattern can > > > > > + repeat on the right side. Each bar's height must always take up the > > > > > + full sensor pixel array height. > > > > > + - name: SensorTestPatternModeColorBarsFadeToGray > > > > > + value: 3 > > > > > + description: | > > > > > + The test pattern is similar to SensorTestPatternModeColorBars, > > > > > + except that each bar should start at its specified color at the top > > > > > + and fade to gray at the bottom. Furthermore each bar is further > > > > > + subdevided into a left and right half. The left half should have a > > > > > + smooth gradient, and the right half should have a quantized > > > > > + gradient. In particular, the right half's should consist of blocks > > > > > + of the same color for 1/16th active sensor pixel array width. The > > > > > + least significant bits in the quantized gradient should be copied > > > > > + from the most significant bits of the smooth gradient. The height of > > > > > + each bar should always be a multiple of 128. When this is not the > > > > > + case, the pattern should repeat at the bottom of the image. > > > > > > > > Do you know what sensor implements this ? I've never seen it before. > > > > > > I think ov13858 produces this as "Vertical Color Bar Type 2". > > > IMX219 also produces as "Grey Color Bars". > > > > > > > > + - name: SensorTestPatternModePn9 > > > > > + value: 4 > > > > > + description: | > > > > > + All pixel data is replaced by a pseudo-random sequence generated > > > > > + from a PN9 512-bit sequence (typically implemented in hardware with > > > > > + a linear feedback shift register). The generator should be reset at > > > > > + the beginning of each frame, and thus each subsequent raw frame with > > > > > + this test pattern should be exactly the same as the last. > > > > > > > > Same question. > > > > > > IMX219 produces "PN9". > > > > > > > > + - name: SensorTestPatternModeCustom1 > > > > > + value: 5 > > > > > + description: | > > > > > + The first custom test pattern. All custom patterns that are > > > > > + available only on this camera device are at least this numeric > > > > > + value. All of the custom test patterns will be static (that is the > > > > > + raw image must not vary from frame to frame). > > > > > > > > Could we figure out a better way to implement support for custom test > > > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for > > > > new patterns to be defined. Starting at a higher value would be an > > > > option, but I'd like to find a good way to handle custom values, for all > > > > controls that have the same issue. > > > > > > That's a good question. I think we're not so interested in custom > > > values right now. > > > So we can drop this now. Is it fine?
On Tue, Apr 20, 2021 at 10:27 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > Hi Hiro, > > On Tue, Apr 13, 2021 at 05:42:07PM +0900, Hirokazu Honda wrote: > > On Tue, Apr 13, 2021 at 5:26 PM Hirokazu Honda wrote: > > > On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda wrote: > > > > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart wrote: > > > > > On Fri, Apr 09, 2021 at 01:32:04PM +0900, Hirokazu Honda wrote: > > > > > > The control is used to report available sensor test pattern modes > > > > > > and also specify the mode to sensor. > > > > > > > > > > > > Signed-off-by: Hirokazu Honda <hiroh@chromium.org> > > > > > > --- > > > > > > src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ > > > > > > 1 file changed, 59 insertions(+) > > > > > > > > > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml > > > > > > index b4771f9d..be2f710a 100644 > > > > > > --- a/src/libcamera/control_ids.yaml > > > > > > +++ b/src/libcamera/control_ids.yaml > > > > > > @@ -608,4 +608,63 @@ controls: > > > > > > detection, additional format conversions etc) count as an additional > > > > > > pipeline stage. > > > > > > > > > > > > + - SensorTestPatternMode: > > > > > > > > > > Does this need to be limited to the sensor, or can we also produce the > > > > > test pattern on the ISP side ? I'm thinking about SoCs that have a test > > > > > pattern generator in the inline ISP, in the Bayer domain, just after the > > > > > CSI-2 receiver. > > > > > > > > Shall I just name TestPatternMode? > > > > > > > > > > + type: int32_t > > > > > > + draft: true > > > > > > + description: | > > > > > > + Control to select the sensor test pattern mode. Currently identical to > > > > > > + ANDROID_SENSOR_TEST_PATTERN_MODE. > > > > > > + > > > > > > + Mode of operation for the test pattern mode. > > > > > > + enum: > > > > > > + - name: SensorTestPatternModeOff > > > > > > + value: 0 > > > > > > + description: | > > > > > > + No test pattern mode is used. The camera device returns from the > > > > > > + image sensor. > > > > > > + - name: SensorTestPatternModeSolidColor > > > > > > + value: 1 > > > > > > + description: | > > > > > > + Each pixel in [R, G_even, G_odd, B] is replaced by its respective > > > > > > + color channel. > > > > > > > > > > How do we pick the colour ? > > > > > > This definition is based on bayer pattern. > > > All pixels in a frame of the solid color test pattern are identical, > > > like all green. > > > cf.) https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#SENSOR_TEST_PATTERN_MODE_SOLID_COLOR > > > > +Tomasz Figa Please correct me if I'm wrong. > > Don't we also need an equivalent to > https://developer.android.com/reference/android/hardware/camera2/CaptureRequest#SENSOR_TEST_PATTERN_DATA > ? > Thanks for catching. Yes, you're right. I think we should add it. I will do it in another patch series. -Hiro > > > > > > + - name: SensorTestPatternModeColorBars > > > > > > + value: 2 > > > > > > + description: | > > > > > > + All pixel data is replaced with an 8-bar color pattern. The vertical > > > > > > + bars (left-to-right) are as follows; white, yellow, cyan, green, > > > > > > + magenta, red, blue and black. Each bar should take up 1/8 of the > > > > > > + sensor pixel array width. When this is not possible, the bar size > > > > > > + should be rounded down to the nearest integer and the pattern can > > > > > > + repeat on the right side. Each bar's height must always take up the > > > > > > + full sensor pixel array height. > > > > > > + - name: SensorTestPatternModeColorBarsFadeToGray > > > > > > + value: 3 > > > > > > + description: | > > > > > > + The test pattern is similar to SensorTestPatternModeColorBars, > > > > > > + except that each bar should start at its specified color at the top > > > > > > + and fade to gray at the bottom. Furthermore each bar is further > > > > > > + subdevided into a left and right half. The left half should have a > > > > > > + smooth gradient, and the right half should have a quantized > > > > > > + gradient. In particular, the right half's should consist of blocks > > > > > > + of the same color for 1/16th active sensor pixel array width. The > > > > > > + least significant bits in the quantized gradient should be copied > > > > > > + from the most significant bits of the smooth gradient. The height of > > > > > > + each bar should always be a multiple of 128. When this is not the > > > > > > + case, the pattern should repeat at the bottom of the image. > > > > > > > > > > Do you know what sensor implements this ? I've never seen it before. > > > > > > > > I think ov13858 produces this as "Vertical Color Bar Type 2". > > > > IMX219 also produces as "Grey Color Bars". > > > > > > > > > > + - name: SensorTestPatternModePn9 > > > > > > + value: 4 > > > > > > + description: | > > > > > > + All pixel data is replaced by a pseudo-random sequence generated > > > > > > + from a PN9 512-bit sequence (typically implemented in hardware with > > > > > > + a linear feedback shift register). The generator should be reset at > > > > > > + the beginning of each frame, and thus each subsequent raw frame with > > > > > > + this test pattern should be exactly the same as the last. > > > > > > > > > > Same question. > > > > > > > > IMX219 produces "PN9". > > > > > > > > > > + - name: SensorTestPatternModeCustom1 > > > > > > + value: 5 > > > > > > + description: | > > > > > > + The first custom test pattern. All custom patterns that are > > > > > > + available only on this camera device are at least this numeric > > > > > > + value. All of the custom test patterns will be static (that is the > > > > > > + raw image must not vary from frame to frame). > > > > > > > > > > Could we figure out a better way to implement support for custom test > > > > > pattern modes ? Having Custom1 immediately following Pn9 won't allow for > > > > > new patterns to be defined. Starting at a higher value would be an > > > > > option, but I'd like to find a good way to handle custom values, for all > > > > > controls that have the same issue. > > > > > > > > That's a good question. I think we're not so interested in custom > > > > values right now. > > > > So we can drop this now. Is it fine? > > -- > Regards, > > Laurent Pinchart
diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml index b4771f9d..be2f710a 100644 --- a/src/libcamera/control_ids.yaml +++ b/src/libcamera/control_ids.yaml @@ -608,4 +608,63 @@ controls: detection, additional format conversions etc) count as an additional pipeline stage. + - SensorTestPatternMode: + type: int32_t + draft: true + description: | + Control to select the sensor test pattern mode. Currently identical to + ANDROID_SENSOR_TEST_PATTERN_MODE. + + Mode of operation for the test pattern mode. + enum: + - name: SensorTestPatternModeOff + value: 0 + description: | + No test pattern mode is used. The camera device returns from the + image sensor. + - name: SensorTestPatternModeSolidColor + value: 1 + description: | + Each pixel in [R, G_even, G_odd, B] is replaced by its respective + color channel. + - name: SensorTestPatternModeColorBars + value: 2 + description: | + All pixel data is replaced with an 8-bar color pattern. The vertical + bars (left-to-right) are as follows; white, yellow, cyan, green, + magenta, red, blue and black. Each bar should take up 1/8 of the + sensor pixel array width. When this is not possible, the bar size + should be rounded down to the nearest integer and the pattern can + repeat on the right side. Each bar's height must always take up the + full sensor pixel array height. + - name: SensorTestPatternModeColorBarsFadeToGray + value: 3 + description: | + The test pattern is similar to SensorTestPatternModeColorBars, + except that each bar should start at its specified color at the top + and fade to gray at the bottom. Furthermore each bar is further + subdevided into a left and right half. The left half should have a + smooth gradient, and the right half should have a quantized + gradient. In particular, the right half's should consist of blocks + of the same color for 1/16th active sensor pixel array width. The + least significant bits in the quantized gradient should be copied + from the most significant bits of the smooth gradient. The height of + each bar should always be a multiple of 128. When this is not the + case, the pattern should repeat at the bottom of the image. + - name: SensorTestPatternModePn9 + value: 4 + description: | + All pixel data is replaced by a pseudo-random sequence generated + from a PN9 512-bit sequence (typically implemented in hardware with + a linear feedback shift register). The generator should be reset at + the beginning of each frame, and thus each subsequent raw frame with + this test pattern should be exactly the same as the last. + - name: SensorTestPatternModeCustom1 + value: 5 + description: | + The first custom test pattern. All custom patterns that are + available only on this camera device are at least this numeric + value. All of the custom test patterns will be static (that is the + raw image must not vary from frame to frame). + ...
The control is used to report available sensor test pattern modes and also specify the mode to sensor. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> --- src/libcamera/control_ids.yaml | 59 ++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+)