Hi Niklas,
Thank you for the patch.
On Friday 02 Sep 2016 15:47:13 Niklas Söderlund wrote:
> The format is used on the R-Car VSP1 video queues that carry
> 2-D histogram statistics data.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
> Documentation/media/uapi/v4l/meta-formats.rst | 1 +
> .../media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst | 150 ++++++++++++++++++
> drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
> include/uapi/linux/videodev2.h | 3 +-
> 4 files changed, 154 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
[snip]
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
> b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst new file mode
> 100644
> index 0000000..a093f0a
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-vsp1-hgt.rst
> @@ -0,0 +1,150 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _v4l2-meta-fmt-vsp1-hgt:
> +
> +*******************************
> +V4L2_META_FMT_VSP1_HGT ('VSPT')
> +*******************************
> +
> +*man V4L2_META_FMT_VSP1_HGT(2)*
> +
> +Renesas R-Car VSP1 2-D Histogram Data
> +
> +
> +Description
> +===========
> +
> +This format describes histogram data generated by the Renesas R-Car VSP1
> +2-D Histogram (HGT) engine.
> +
> +The VSP1 HGT is a histogram computation engine that operates on HSV
> +data. It operates on a possibly cropped and subsampled input image and
> +computes the sum, maximum and minimum of the S component as well as a
> +weighted frequency histogram based on the H and S components.
> +
> +The histogram is a matrix of 6 Hue and 32 Saturation buckets, 192 in
> +total. Each HSV value is added to one or more buckets with a wight
s/wight/weight/
> +between 1 and 16 depending on how the Hue areas are setup.
I would say 'depending on the Hue areas configuration' to insist on the fact
that the configuration can be changed by the application.
> Finding the
> +correct buckets is done by inspecting the H and S value independently.
Maybe s/correct/corresponding/ ?
> +The Saturation position **n** (0 - 31) in the matrix are found by the
Maybe s/in the matrix/of the bucket/, or s/in the matrix/of the bucket in the
matrix/ ?
s/are found/is found/ or maybe 'is computed' ?
> +expression:
> +
> + 8 * n <= S < 8 * (n + 1)
How about simply 'n = S / 8' ?
> +The Hue positions **m** (0 - 5) in the matrix depends on how the HGT Hue
s/positions/position/
> +areas are configured. There are 6 user configurable Hue Areas which can
> +be configured to cover overlapping Hue values:
> +
> +::
> +
> + Area 0 Area 1 Area 2 Area 3 Area 4
> Area 5 + ________ ________ ________ ________
> ________ ________ + \ /| |\ /| |\ /| |\ /|
> |\ /| |\ /| |\ / + \ / | | \ / | | \ / |
> | \ / | | \ / | | \ / | | \ / + X | | X | |
> X | | X | | X | | X | | X + / \ | | /
> \ | | / \ | | / \ | | / \ | | / \ | | / \ + /
> \| |/ \| |/ \| |/ \| |/ \| |/ \| |/
> \ + 5U 0L 0U 1L 1U 2L 2U 3L 3U 4L 4U
> 5L 5U 0L + <0..............................Hue
> Value............................255>
> +
> +As shown in the diagram a single Hue vale can be attributed to more then
s/vale/value/
s/then/than/
> +one Hue area. In such case the Hue value is attributed to both Hue
> +Areas, but with a weight. The maximum weight is 16 and is associated
> +with all Hue values that are inside the center of a Hue area (between nL
> +-- nU). Values outside this area are weighted with a rounded down value
> +along the diagonal line. If there is no overlapped areas specified the
> +value is included in the lower area.
This sounds a bit confusing to me. How about the following ?
"The Hue position **m** (0 - 5) of the bucket [in the matrix]* depends on how
the HGT Hue areas are configured. There are 6 user configurable Hue Areas
which can be configured to cover overlapping Hue values:
[diagram]
When two consecutive areas don't overlap (n+1L is equal to nU) the boundary
value is considered as part of the lower area.
Pixels with a hue value included in the centre of an area (between nL and nU
included) are are attributed to that single area and given a weight of 16.
Pixels with a hue value included in the overlapping region between two areas
(between n+1L and nU excluded) are attributed to both areas and given a weight
for each of these areas proportional to their position along the diagonal
lines (rounded down)."
* Add "in the matrix" depending on the wording of the saturation description.
> +The Hue area setup must match one of the following constrains:
> +
> +::
> +
> + 0L <= 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U
> +
> +::
> +
> + 0U <= 1L <= 1U <= 2L <= 2U <= 3L <= 3U <= 4L <= 4U <= 5L <= 5U <= 0L
> +
> +**Byte Order.**
> +All data is stored in memory in little endian format. Each cell in the
> tables +contains one byte.
> +
> +.. flat-table:: VSP1 HGT Data - (800 bytes)
> + :header-rows: 2
> + :stub-columns: 0
> +
> + * - Offset
> + - :cspan:`4` Memory
> + * -
> + - [31:24]
> + - [23:16]
> + - [15:8]
> + - [7:0]
> + * - 0
> + - -
> + - S max [7:0]
> + - -
> + - S min [7:0]
> + * - 4
> + - :cspan:`4` S sum [31:0]
> + * - 8
> + - -
> + - Hue Area 0 Lower Boundary (0L) [0:7]
> + - -
> + - Hue Area 0 Upper Boundary (0U) [0:7]
> + * - 12
> + - -
> + - Hue Area 1 Lower Boundary (1L) [0:7]
> + - -
> + - Hue Area 1 Upper Boundary (1U) [0:7]
> + * - 16
> + - -
> + - Hue Area 2 Lower Boundary (2L) [0:7]
> + - -
> + - Hue Area 2 Upper Boundary (2U) [0:7]
> + * - 20
> + - -
> + - Hue Area 3 Lower Boundary (3L) [0:7]
> + - -
> + - Hue Area 3 Upper Boundary (3U) [0:7]
> + * - 24
> + - -
> + - Hue Area 4 Lower Boundary (4L) [0:7]
> + - -
> + - Hue Area 4 Upper Boundary (4U) [0:7]
> + * - 28
> + - -
> + - Hue Area 5 Lower Boundary (5L) [0:7]
> + - -
> + - Hue Area 5 Upper Boundary (5U) [0:7]
What's the rationale for including the boundaries in the statistics buffer ?
Boundaries are configured by userspace, they should be known to the
application already.
> + * - 32
> + - :cspan:`4` Histogram bucket (m=0, n=0) [31:0]
> + * - 36
> + - :cspan:`4` Histogram bucket (m=0, n=1) [31:0]
> + * -
> + - :cspan:`4` ...
> + * - 156
> + - :cspan:`4` Histogram bucket (m=0, n=31) [31:0]
> + * - 160
> + - :cspan:`4` Histogram bucket (m=1, n=0) [31:0]
> + * -
> + - :cspan:`4` ...
> + * - 288
> + - :cspan:`4` Histogram bucket (m=2, n=0) [31:0]
> + * -
> + - :cspan:`4` ...
> + * - 416
> + - :cspan:`4` Histogram bucket (m=3, n=0) [31:0]
> + * -
> + - :cspan:`4` ...
> + * - 544
> + - :cspan:`4` Histogram bucket (m=4, n=0) [31:0]
> + * -
> + - :cspan:`4` ...
> + * - 672
> + - :cspan:`4` Histogram bucket (m=5, n=0) [31:0]
> + * -
> + - :cspan:`4` ...
> + * - 796
> + - :cspan:`4` Histogram bucket (m=5, n=31) [31:0]
[snip]
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
