summaryrefslogtreecommitdiff
path: root/src/qcam/assets/feathericons/arrow-left-circle.svg
diff options
context:
space:
mode:
authorPaul Elder <paul.elder@ideasonboard.com>2020-06-29 22:00:53 +0900
committerPaul Elder <paul.elder@ideasonboard.com>2020-07-10 16:10:55 +0900
commit5791fdc1cb98b7c1e7ef9cce3405d5e6013fa832 (patch)
treefc38308025de7be56480910bdfb3ebcb310f57a4 /src/qcam/assets/feathericons/arrow-left-circle.svg
parentf827c6363d19cf3514aa32e6604f9b3391a9a8dc (diff)
libcamera: formats: Add fields to info to ease calculating stride
Packed formats make it difficult to calculate stride as well as frame size with the fields that PixelFormatInfo currently has. bitsPerPixel is defined as the average number of bits per pixel, and only counts effective bits, so it is not useful for calculating stride and frame size. To fix this, we introduce a concept of a "pixel group". The size of this group is defined as the minimum number of pixels (including padding) necessary in a row when the image has only one column of effective pixels. The pixel group has one more attribute, that is the "bytes per group". This determines how many bytes one pixel group consumes. These are the fields pixelsPerGroup and bytesPerGroup that are defined in this patch. Defining these two values makes it really simple to calculate bytes-per-line, as ceil(width / pixelsPerGroup) * bytesPerGroup, where width is measured in number of pixels. The ceiling accounts for padding. The pixel group has another contraint, which is that the pixel group (bytesPerGroup and pixelsPerGroup) is the smallest repeatable unit. What this means is that, for example, in the IPU3 formats, if there is only one column of effective pixels, it looks like it could be fit in 5 bytes with 3 padding pixels (for a total of 4 pixels over 5 bytes). However, this unit is not repeatable, as at the 7th group in the same row, the pattern is broken. Therefore, the pixel group for IPU3 formats must be 25 pixels over 32 bytes. Clearly, pixelsPerGroup must be constant for all planes in the format. The bytesPerGroup then, must be a per-plane attribute. There is one more field, verticalSubSampling, that is per-plane. This is simply a divider, to divide the number of rows of pixels by the sub-sampling value, to obtain the number of rows of pixels for the subsampled plane. For example, for something simple like BGR888, it is self-explanatory: the pixel group size is 1, and the bytes necessary is 3, and there is only one plane with no (= 1) vertical subsampling. For YUYV, the CbCr pair is shared between two pixels, so even if you have only one pixel, you would still need a padded second Y, therefore the pixel group size is 2, and bytes necessary is 4 (as opposed to 1 and 2). YUYV also has no vertical subsampling. NV12 has a pixel group size of 2 pixels, due to the CbCr plane. The bytes per group then, for both planes, is 2. The first plane has no vertical subsampling, but the second plane is subsampled by a factor of 2. The IPU3 formats are also self-explanatory, as they are single-planar, and have a pixel group size of 25, consuming 32 bytes. Although a comment in the driver suggests that it should be 50 and 64, respectively, this is an attribute of the driver, and not the format, so this shall be set by the ipu3 pipeline handler. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Diffstat (limited to 'src/qcam/assets/feathericons/arrow-left-circle.svg')
0 files changed, 0 insertions, 0 deletions