Я написал преобразование из YUV_420_888 в Bitmap, учитывая следующую логику (как я ее понимаю):
Подводя итог подходу: координаты ядер x и y сравнимы как с x, так и с y бездонной части Y-плоскости (2d-распределение) и x и y выходного битового массива. Однако U- и V-Planes имеют другую структуру, чем Y-Plane, поскольку они используют 1 байт для покрытия 4 пикселей и, кроме того, могут иметь PixelStride, который более одного, кроме того, они могут также имеют прокладку, которая может отличаться от прокладки Y-плоскости. Поэтому для эффективного доступа к Us и Vs ядром я помещаю их в 1-ю выделение и создавал индекс "uvIndex", который дает положение соответствующих U- и V в пределах этого 1-го распределения для данного ( x, y) в (без прокладки) Y-плоскости (и, следовательно, выходной битмап).
Чтобы сохранить ядро rs-Kernel, я исключил область заполнения в yPlane, закрыв x-диапазон через LaunchOptions (это отражает RowStride у-плоскости, который, таким образом, можно игнорировать в ядре). Поэтому нам просто нужно рассмотреть uvPixelStride и uvRowStride в uvIndex, то есть индекс, используемый для доступа к значениям u- и v.
Это мой код:
Ядро Renderscript, названное yuv420888.rs
#pragma version(1)
#pragma rs java_package_name(com.xxxyyy.testcamera2);
#pragma rs_fp_relaxed
int32_t width;
int32_t height;
uint picWidth, uvPixelStride, uvRowStride ;
rs_allocation ypsIn,uIn,vIn;
// The LaunchOptions ensure that the Kernel does not enter the padding zone of Y, so yRowStride can be ignored WITHIN the Kernel.
uchar4 __attribute__((kernel)) doConvert(uint32_t x, uint32_t y) {
// index for accessing the uIn and vIn's
uint uvIndex= uvPixelStride * (x/2) + uvRowStride*(y/2);
// get the y,u,v values
uchar yps= rsGetElementAt_uchar(ypsIn, x, y);
uchar u= rsGetElementAt_uchar(uIn, uvIndex);
uchar v= rsGetElementAt_uchar(vIn, uvIndex);
// calc argb
int4 argb;
argb.r = yps + v * 1436 / 1024 - 179;
argb.g = yps -u * 46549 / 131072 + 44 -v * 93604 / 131072 + 91;
argb.b = yps +u * 1814 / 1024 - 227;
argb.a = 255;
uchar4 out = convert_uchar4(clamp(argb, 0, 255));
return out;
}
Сторона Java:
private Bitmap YUV_420_888_toRGB(Image image, int width, int height){
// Get the three image planes
Image.Plane[] planes = image.getPlanes();
ByteBuffer buffer = planes[0].getBuffer();
byte[] y = new byte[buffer.remaining()];
buffer.get(y);
buffer = planes[1].getBuffer();
byte[] u = new byte[buffer.remaining()];
buffer.get(u);
buffer = planes[2].getBuffer();
byte[] v = new byte[buffer.remaining()];
buffer.get(v);
// get the relevant RowStrides and PixelStrides
// (we know from documentation that PixelStride is 1 for y)
int yRowStride= planes[0].getRowStride();
int uvRowStride= planes[1].getRowStride(); // we know from documentation that RowStride is the same for u and v.
int uvPixelStride= planes[1].getPixelStride(); // we know from documentation that PixelStride is the same for u and v.
// rs creation just for demo. Create rs just once in onCreate and use it again.
RenderScript rs = RenderScript.create(this);
//RenderScript rs = MainActivity.rs;
ScriptC_yuv420888 mYuv420=new ScriptC_yuv420888 (rs);
// Y,U,V are defined as global allocations, the out-Allocation is the Bitmap.
// Note also that uAlloc and vAlloc are 1-dimensional while yAlloc is 2-dimensional.
Type.Builder typeUcharY = new Type.Builder(rs, Element.U8(rs));
typeUcharY.setX(yRowStride).setY(height);
Allocation yAlloc = Allocation.createTyped(rs, typeUcharY.create());
yAlloc.copyFrom(y);
mYuv420.set_ypsIn(yAlloc);
Type.Builder typeUcharUV = new Type.Builder(rs, Element.U8(rs));
// note that the size of the u and v are as follows:
// ( (width/2)*PixelStride + padding ) * (height/2)
// = (RowStride ) * (height/2)
// but I noted that on the S7 it is 1 less...
typeUcharUV.setX(u.length);
Allocation uAlloc = Allocation.createTyped(rs, typeUcharUV.create());
uAlloc.copyFrom(u);
mYuv420.set_uIn(uAlloc);
Allocation vAlloc = Allocation.createTyped(rs, typeUcharUV.create());
vAlloc.copyFrom(v);
mYuv420.set_vIn(vAlloc);
// handover parameters
mYuv420.set_picWidth(width);
mYuv420.set_uvRowStride (uvRowStride);
mYuv420.set_uvPixelStride (uvPixelStride);
Bitmap outBitmap = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888);
Allocation outAlloc = Allocation.createFromBitmap(rs, outBitmap, Allocation.MipmapControl.MIPMAP_NONE, Allocation.USAGE_SCRIPT);
Script.LaunchOptions lo = new Script.LaunchOptions();
lo.setX(0, width); // by this we ignore the y’s padding zone, i.e. the right side of x between width and yRowStride
lo.setY(0, height);
mYuv420.forEach_doConvert(outAlloc,lo);
outAlloc.copyTo(outBitmap);
return outBitmap;
}
Тестирование на Nexus 7 (API 22) дает хорошие цветовые растровые изображения. Однако это устройство имеет тривиальные пиксельные полосы (= 1) и отсутствие прокладки (то есть rowstride = width). Тестирование на brandnew Samsung S7 (API 23) Я получаю картинки, цвета которых неправильны - кроме зеленых. Но картинка не показывает общего смещения по направлению к зеленому, просто кажется, что не зеленые цвета не воспроизводятся правильно. Обратите внимание, что S7 применяет пиксельную полосу u/v, равную 2, и никакое отступы.
Поскольку самая важная строка кода находится внутри rs-кода, доступ к u/v-плоскостям uint uvIndex = (...) Я думаю, может возникнуть проблема, возможно, с неправильным рассмотрением пикселей. Кто-нибудь видит решение? Спасибо.
UPDATE: я проверил все, и я уверен, что код относительно доступа y, u, v правильный. Таким образом, проблема должна быть связана с самими значениями u и v. Не зеленые цвета имеют фиолетовый наклон, и, глядя на значения u, v, они, кажется, находятся в довольно узком диапазоне около 110-150. Действительно ли возможно, что нам нужно справляться с конкретными устройствами YUV → RBG конверсий...?! Я что-то пропустил?
UPDATE 2: скорректированный код, теперь он работает благодаря Eddy Feedback.