[libcamera-devel] [RFC PATCH 1/5] libcamera: controls: Add sensor test pattern mode

[Hirokazu Honda]

On Tue, Apr 13, 2021 at 5:26 PM Hirokazu Honda <hiroh at chromium.org> wrote:
>
> On Tue, Apr 13, 2021 at 5:10 PM Hirokazu Honda <hiroh at chromium.org> wrote:
> >
> > On Tue, Apr 13, 2021 at 9:37 AM Laurent Pinchart
> > <laurent.pinchart at 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 at 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