Functions and Restrictions
Function Description
JPEG Decoder (JPEGD) implements .jpg, .jpeg, .JPG, and .JPEG image decoding.
- JPEGD supports image rotation during image decoding.
If the input stream contains orientation information (the orientation of the camera to the scene when the image is captured), JPEGD parses the orientation information during decoding and rotates the image by 90º, 180º, or 270º, or mirrors the image. The width stride, height stride, and output buffer of the rotated image must meet the restrictions described in Restrictions on Image Formats, Width and Height Alignment, and Buffers.
If the stream of the input image is abnormal, JPEGD fails to read the orientation information. As a result, the image rotation function cannot be implemented.
For the following product models, if the height of the original image is an odd number and the rotation mode is to exchange the width and height, black borders exist in the width after rotation. You are advised to align the width downward to an even number (that is, remove the black borders). Take a JPEGD 422 rotated image as an example. If the original size is 200 x 101 and the size after rotation is 101 x 200, the recommended actual size is 100 x 200. Take another JPEGD 440 rotated image as an example. If the original size is 201 x 101 and the size after rotation is 100 x 201, the recommended actual size is 100 x 200.- Atlas 350 Accelerator Card
Atlas A3 training product /Atlas A3 inference product Atlas A2 training product /Atlas A2 inference product Atlas 200I/500 A2 inference product
- JPEGD supports retaining the source image format during image decoding.
The image encoding formats before and after decoding remain consistent. For example, if the source format is JPEG(440), the destination format is YUV440SP with V component before U component or YUV440SP with U component before V component.
Use the source image format for decoding in either of the following ways:
- Call acldvppJpegGetImageInfoV2 to obtain the source image format before JPEGD decoding. In the JPEGD decoding API call, set the format of the output image to be the same as that of the input image.
- In the JPEGD decoding API call, set the output format to PIXEL_FORMAT_UNKNOWN to get a semi-planar output in the source format with V component before U component. For example, if the source format is JPEG(440) and the destination format is set to PIXEL_FORMAT_UNKNOWN, the JPEGD destination format is YUV440SP with V component before U component.
If the JPEGD destination image will be fed to a model for inference, you are advised to set the output image format to PIXEL_FORMAT_UNKNOWN. In this case, JPEGD decodes with the source format preserved (ensure that the JPEGD destination format is supported by the model) to avoid inference accuracy drop.
Resolution Restrictions
Model |
Resolution Range |
|---|---|
32 x 32 to 8192 x 8192 |
|
32 x 32 to 16384 x 16384 |
Output image resolution:
JPEGD only decodes images and does not change the image resolution. Therefore, the resolution of the output image is the same as that of the input image.
Restrictions on Image Formats, Width and Height Alignment, and Buffers
JPEGD supports only Huffman coding and does not support arithmetic encoding, progressive JPEG format, or JPEG 2000 format. The color space of the input image must be YUV with YUV components in the ratio of 4:4:4, 4:2:2, 4:2:0, 4:0:0, or 4:4:0.
The following table lists the output image formats supported by JPEGD. For the definition of the output image format, see acldvppPixelFormat. For , the YUV400 8-bit format is supported, and
The alignment restrictions of width stride x height stride vary according to products. For details about the width stride and height stride, see Terminology.
- For the following product models, the width stride x height stride must be 64 x 16 aligned:
Atlas A3 training product /Atlas A3 inference product Atlas A2 training product /Atlas A2 inference product Atlas 200I/500 A2 inference product Atlas inference product - For the following product models, the width stride x height stride must be 128 x 16 aligned:
When decoding JPEGD images, you need to call the acldvppMalloc API to allocate the input and output buffers on the device, and call the acldvppFree API to free the input and output buffers. The lifecycle of the buffers is managed by the user. The size of the input buffer is the size of space occupied by the input image. The size of the output buffer refers to the size of the buffer for storing the output image. You can call the acldvppJpegPredictDecSize API to estimate the size. For details about the calculation formula, see the following table.
Input Format (YUV) |
Output Format |
Output Width and Height |
Requirements on the output image buffer size |
|---|---|---|---|
JPEG(444) |
YVU444SP 8-bit YUV444SP 8bit |
No alignment requirement. |
Buffer size (in bytes) ≥ Width stride x Height stride x 3 |
jpeg(444) |
YUV420SP NV12 8-bit YUV420SP NV21 8bit |
Width: Must be a multiple of 2. Height: Must be a multiple of 2. |
Buffer size (in bytes) ≥ Width stride x Height stride x 3/2 |
JPEG(422) |
YVU422SP 8-bit YUV422SP 8bit |
Width: Must be a multiple of 2. Height: Must be a multiple of 2. |
Buffer size (in bytes) ≥ Width stride x Height stride x 2 |
jpeg(422) |
YUV420SP NV12 8-bit YUV420SP NV21 8bit |
Width: Must be a multiple of 2. Height: Must be a multiple of 2. |
Buffer size (in bytes) ≥ Width stride x Height stride x 3/2 |
JPEG(420) |
YUV420SP NV12 8-bit YUV420SP NV21 8bit |
Width: Must be a multiple of 2. Height: Must be a multiple of 2. |
Buffer size (in bytes) ≥ Width stride x Height stride x 3/2 |
JPEG(400) |
YUV420SP NV12 8-bit YUV420SP NV21 8bit |
Width: Must be a multiple of 2. Height: Must be a multiple of 2. |
Buffer size (in bytes) ≥ Width stride x Height stride x 3/2 |
jpeg(400) |
YUV400 8-bit |
No alignment requirement. |
Buffer size (in bytes) ≥ Width stride x Height stride |
JPEG(440) |
YVU440SP 8-bit YUV440SP 8bit |
Width: Must be a multiple of 2. Height: Must be a multiple of 2. |
Buffer size (in bytes) ≥ Width stride x Height stride x 2 |
jpeg(440) |
YUV420SP NV12 8-bit YUV420SP NV21 8bit |
Width: Must be a multiple of 2. Height: Must be a multiple of 2. |
Buffer size (in bytes) ≥ Width stride x Height stride x 3/2 |
Note: If the JPEGD output image is used as the input of VPC and the source image format is used for decoding, check whether VPC supports the JPEGD output image format. For details about the VPC input image format, see Restrictions. If VPC does not support the JPEGD output image format, you need to specify the JPEGD output image format based on VPC requirements.
Requirements for Software and Hardware
- Hardware requirements
- A maximum of four Huffman tables are supported, including two direct coefficient (DC) tables and two alternating coefficient (AC) tables.
- A maximum of three quantization tables are supported.
- Only 8-bit sampling is supported.
- Only sequentially-encoded images can be decoded.
- Only JPEG decoding based on discrete cosine transform (DCT) is supported.
- Only one start of scan (SOS) marker is allowed for image decoding.
- Software requirements
- A maximum of three SOS markers are allowed for image decoding.
- Decoding of abnormal images with insufficient data in minimum coded units (MCUs) is supported.
Accuracy Restrictions
In the event of JPEGD+VPC cascade, width stride × height stride of the JPEGD output image has alignment restrictions, so there are some invalid paddings. Therefore, when executing VPC functions such as resizing, call acldvppSetPicDescWidth and acldvppSetPicDescHeight to correctly set the original width and height of the input image. As such, VPC will automatically crop the image based on the width and height of the source image before resizing the image, eliminating the impact of invalid data on image accuracy.