关于ScriptIntrinsicYuvToRGB的YUV格式及使用相关技术问询

Let’s break down each of your questions with practical, actionable answers based on Android’s RenderScript docs and real-world usage:

1. Which YUV ImageFormats does SIYTB support? #

SIYTB officially supports three standard YUV 4:2:0 formats:

• ImageFormat.NV21 (Y plane followed by interleaved UV pixels)
• ImageFormat.YV12 (planar Y, U, V planes in sequence)
• ImageFormat.YUV_420_888 (flexible planar format that can represent NV21, YV12, or other 4:2:0 variants)

These are the only formats documented to work reliably with SIYTB—using others may cause distorted output or errors.

2. What Element should be used with SIYTB.create()? #

The docs mention supported element types are U8_4, but since SIYTB outputs RGBA (with alpha fixed to 255), you should use Element.RGBA_8888 for the create call.

Element.RGBA_8888 is a specialized U8_4 element that explicitly defines the channel order as red → green → blue → alpha. This aligns perfectly with SIYTB’s output, makes your code more readable, and ensures the allocation matches the expected format. Plain U8_4 would work technically, but RGBA_8888 is the intuitive choice here.

3. What Element type to use for the input Allocation's Type.Builder? #

Yes, you must use Element.YUV when building the input Type.

SIYTB requires the input allocation to be described as a YUV element to properly recognize and process planar/interleaved YUV data. Using any other element type (like U8) will cause SIYTB to misinterpret the input bytes.

4. Should Type.Builder.setY() and setX() be used for input Allocations? #

Absolutely—these methods define the dimensions of the Y plane (the full width and height of your image), and this applies to all three supported formats:

• setX() should be set to the full width of the image (since the Y plane has one pixel per image pixel)
• setY() should be set to the full height of the image

The UV planes’ dimensions are automatically derived based on the YUV format you specify (e.g., half width/height for 4:2:0 sampling), so you don’t need to set those explicitly.

5. Should Type.Builder.setYuvFormat() be used? #

Yes, this is a critical step for all three supported formats.

Calling setYuvFormat() with your target ImageFormat (e.g., ImageFormat.NV21) tells SIYTB exactly how to parse the input data—including plane order, interleaving, and sampling structure. Without this, SIYTB has no way to correctly interpret the byte array layout, leading to distorted RGB output.

6. What layout is required for the input byte array when using Allocator.copyFrom()? #

The byte array must follow the compact, standard layout matching the YUV format you specified with setYuvFormat():

• For NV21: Y plane (full width × height) followed by interleaved UV pixels (arranged as VU pairs)
• For YV12: Planar Y, then U, then V (each plane has no row padding)
• For YUV_420_888: The byte array must match the plane order/packing of the underlying format (e.g., use NV21 layout if your YUV_420_888 image is NV21-compatible)

SIYTB relies entirely on setYuvFormat() to unpack the byte array correctly. If your byte array has row strides (padding at the end of rows), you’ll need to create an allocation with matching strides instead of using the compact copyFrom() method.

7. Is there an easy way to convert an Android Image to a byte array? #

Yes! You can extract bytes directly from the Image’s planes using ByteBuffer operations. Here’s a practical example for YUV_420_888 images (adjust based on your specific format):

public static byte[] convertImageToByteArray(Image image) {
    Image.Plane[] planes = image.getPlanes();
    ByteBuffer yBuffer = planes[0].getBuffer();
    ByteBuffer uBuffer = planes[1].getBuffer();
    ByteBuffer vBuffer = planes[2].getBuffer();

    int ySize = yBuffer.remaining();
    int uSize = uBuffer.remaining();
    int vSize = vBuffer.remaining();

    byte[] byteArray = new byte[ySize + uSize + vSize];

    // Copy each plane's bytes into the combined array
    yBuffer.get(byteArray, 0, ySize);
    uBuffer.get(byteArray, ySize, uSize);
    vBuffer.get(byteArray, ySize + uSize, vSize);

    return byteArray;
}

Note: If your Image has non-zero row strides (common in camera outputs), you’ll need to copy each row individually to avoid including padding bytes. For simpler cases, you can also use a RenderScript Allocation to copy directly from the Image and then extract bytes from the allocation.

内容的提问来源于stack exchange，提问作者beyeriii