JPEGD Functions and Restrictions

Functions

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:
- In the JPEGD decoding API call, set the output format to HI_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 HI_PIXEL_FORMAT_UNKNOWN, the JPEGD destination format is YUV440SP with V component before U component.
  In this mode, the output image format is unknown. Therefore, you need to allocate the buffer as large as possible or call the hi_mpi_dvpp_get_image_info API to obtain the size of the decoded output buffer to ensure that the output image can be stored properly.
  
  If the JPEGD destination image will be fed to a model for inference, you are advised to set the output image format to HI_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.
- Call the hi_mpi_dvpp_get_image_info API to obtain the width, height, width stride, height stride, output buffer size, and image format of the output image based on the input JPEG source image, and then call the JPEGD decoding API, use the image format obtained through the hi_mpi_dvpp_get_image_info API to set the output image format.

Resolution Restrictions

Input image resolution::

Model	Resolution Range
Atlas inference product	32 x 32 to 8192 x 8192
Atlas A3 training product / Atlas A3 inference product Atlas A2 training product / Atlas A2 inference product Atlas 200I/500 A2 inference product	32 x 32 to 16384 x 16384
Atlas 350 Accelerator Card	32 x 32 to 32768 x 32768

Model

Resolution Range

Atlas inference product

32 x 32 to 8192 x 8192

Atlas A3 training product / Atlas A3 inference product

Atlas A2 training product / Atlas A2 inference product

Atlas 200I/500 A2 inference product

32 x 32 to 16384 x 16384

Atlas 350 Accelerator Card

32 x 32 to 32768 x 32768

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 Buffer Allocation and Freeing APIs

During JPEGD image decoding, call the hi_mpi_dvpp_malloc\hi_mpi_dvpp_free API to allocate or release the input and output memory on the device. The lifecycle of the memory is managed by the user. The size of the input buffer refers to the actual size occupied by the input image. For details about the size of the output buffer, see the formula in Table 1.

For the following product models, the aclrtMalloc\aclrtFree API can be called to allocate or release the input and output memory on the device. The lifecycle of the memory is managed by users.

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

The memory allocated by calling hi_mpi_dvpp_malloc is the dedicated memory for media data processing. However, the address space of the dedicated memory is limited. If you are concerned about memory planning or memory resources are limited, you are advised to call aclrtMalloc to allocate memory. When the aclrtMalloc interface is called to allocate memory, it is recommended that the memory of the ACL_MEM_MALLOC_HUGE_FIRST type be allocated. The huge page memory is preferentially allocated because the huge page performance is better.

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.

If the JPEGD output image is directly used as the VPC input and the source image format is used for decoding, check whether the VPC supports the format of the decoded output image. For details about the VPC input image format, see Restrictions. If the VPC does not support the format, in this case, you need to specify the output image format of JPEGD based on the VPC.

For details about the output image format, see hi_pixel_format. For details about the width stride and height stride, see Terminology.

**Table 1** Restrictions on the image format, width and height alignment, and buffer size
Input Format (YUV)	Output Format	Output Width and Height	Output Width Stride, Height Stride, and Buffer Size
JPEG(444)	YVU444SP 8-bit	No alignment requirement.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 3
jpeg(444)	YUV444SP 8-bit	No alignment requirement.
jpeg(444)	YUV420SP NV12 8-bit	Width: Must be a multiple of 2. Height: Must be a multiple of 2.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 3/2
jpeg(444)	YUV420SP NV21 8-bit
JPEG(422)	YVU422SP 8-bit	Width: Must be a multiple of 2. Height: No alignment requirement.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 2
jpeg(422)	YUV422SP 8-bit
jpeg(422)	YUV420SP NV12 8-bit	Width: Must be a multiple of 2. Height: Must be a multiple of 2.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 3/2
jpeg(422)	YUV420SP NV21 8-bit
JPEG(420)	YUV420SP NV12 8-bit	Width: Must be a multiple of 2. Height: Must be a multiple of 2.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 3/2
JPEG(420)	YUV420SP NV21 8-bit
JPEG(400)	YUV420SP NV12 8-bit	Width: Must be a multiple of 2. Height: Must be a multiple of 2.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 3/2
jpeg(400)	YUV420SP NV21 8-bit
jpeg(400)	YUV400 8-bit	No alignment requirement.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride
JPEG(440)	YVU440SP 8-bit	Width: No alignment requirement. Height: Must be a multiple of 2.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 2
jpeg(440)	YUV440SP 8-bit
jpeg(440)	YUV420SP NV12 8-bit	Width: Must be a multiple of 2. Height: Must be a multiple of 2.	Width stride: Round up the width to the nearest multiple of 64. Height stride: Round up the height to the nearest multiple of 16. Buffer size (in bytes) ≥ Width stride x Height stride x 3/2
jpeg(440)	YUV420SP NV21 8-bit

Requirements for Software and Hardware

Hardware requirements
- A maximum of four Huffman tables are supported, including two direct current (DC) coefficient tables and two alternating current (AC) coefficient 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.
- Abnormal image decoding with insufficient Minimum Coded Unit (MCU) data is supported.

Accuracy Restrictions

In the event of JPEGD+VPC cascade, widthStride x heightStride of the JPEGD output image must be a multiple of 64 x 16, so there are some invalid paddings. Therefore, when executing VPC functions such as resizing, set hi_vpc_pic_info.picture_width and hi_vpc_pic_info.picture_height to 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 and then resize the image, eliminating the impact of invalid data on image accuracy.

Precautions

If user-defined data exists after the end of image (EOI) marker 0xFFD9, JPEGD clears the 8-byte data after the EOI during decoding. If you want to retain the user-defined data, read it to the buffer and back it up before sending it to JPEGD.

To check whether user-defined data exists after the EOI in an image, use the binary viewing tool to open the image. For example, user-defined data exists after the EOI marker FFD9 in the following figure.

Parent topic: VDEC/JPEGD