Reputation: 95
Afternoon,
I’ve noticed that when requesting Camera2 ImageFormat.YUV_420_888 VGA data on the specified device - Galaxy A23 (SM-A236B) - the Y, U and V channels have unexpected sizes and row strides.
Requesting a similar image reader (ignore syntax correctness!):
mImageReader = ImageReader.NewInstance(640, 480, ImageFormatType.Yuv420888, 5);
yields:
Y row stride = 1024 / Y size bytes = 491136
UV row stride = 1024 / UV pixel stride = 2 / UV size bytes = 245375
when it should be:
Y row stride = 640 / Y size bytes = 307200
UV row stride = 640 / UV pixel stride = 2 / UV size bytes = 153599
This was visible in all Android versions available for this device.
Apart from Y (what i use) not being what is expected, it does break my code of YUV2RGBA (can paste this if necessary for future discussion).
Does anyone know if there is an issue with the Camera2 implementation on this device or if they are returning something that is not YUV_420_888?
Upvotes: 0
Views: 278
Reputation: 18137
There's no expectation that stride == width
. If that was the case, stride
would not need to exist at all.
Many hardware image processing blocks have memory alignment requirements that cause stride
values to have to be larger than width
; in this case it looks like the camera image signal processor (or one of its subunits) needs image buffer rows to be at least 1KB in size.
That's why there is both a row stride and a pixel stride, to allow for efficient generation and access to YUV data of all sorts of layouts.
Ignoring them or assuming stride == width
or pixel stride == 1
(or 2) is a good way to have your app be broken on some subset of devices.
Upvotes: 1
Reputation: 95
For anyone that comes across this, this phone has padding on the Y channel.
For the example of the question the data between 640 (width requested) and 1024(actual y row stride) is all zeros.
(Kind of) Related question here.
Upvotes: 0