| Age | Commit message (Collapse) | Author |
|---|
|
Determine the number of planes used by a format by counting the number
of PixelFormatPlaneInfo entries with a valid entry.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a function which returns PixelFormatInfo, given format name as
a string.
Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ImageFormats helper class is not used anymore and can be removed.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add member functions to PixelFormatInfo for calculating stride and frame
size. This will simplify existing code that calculates these things.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a lookup function for PixelFormatInfo that takes a V4L2PixelFormat.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
Print format names defined in formats namespace instead of the hex
values in toString() as they are easier to comprehend. For this add
a property of 'name' in PixelFormatInfo' so as to map the formats
with their names. Print fourcc for formats which are not used in
libcamera.
Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
With the internal headers now in include/libcamera/internal/, we may
have identically named headers in include/libcamera/. Their header
guards would clash. Rename the header guards of internal headers to
prevent any issue.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The libcamera source files are named after class names, using
snake_case. pixelformats.h and pixelformats.cpp don't comply with that
rule. Fix them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The libcamera internal headers are located in src/libcamera/include/.
The directory is added to the compiler headers search path with a meson
include_directories() directive, and internal headers are included with
(e.g. for the internal semaphore.h header)
#include "semaphore.h"
All was well, until libcxx decided to implement the C++20
synchronization library. The __threading_support header gained a
#include <semaphore.h>
to include the pthread's semaphore support. As include_directories()
adds src/libcamera/include/ to the compiler search path with -I, the
internal semaphore.h is included instead of the pthread version.
Needless to say, the compiler isn't happy.
Three options have been considered to fix this issue:
- Use -iquote instead of -I. The -iquote option instructs gcc to only
consider the header search path for headers included with the ""
version. Meson unfortunately doesn't support this option.
- Rename the internal semaphore.h header. This was deemed to be the
beginning of a long whack-a-mole game, where namespace clashes with
system libraries would appear over time (possibly dependent on
particular system configurations) and would need to be constantly
fixed.
- Move the internal headers to another directory to create a unique
namespace through path components. This causes lots of churn in all
the existing source files through the all project.
The first option would be best, but isn't available to us due to missing
support in meson. Even if -iquote support was added, we would need to
fix the problem before a new version of meson containing the required
support would be released.
The third option is thus the only practical solution available. Bite the
bullet, and do it, moving headers to include/libcamera/internal/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
