# An Image-Retrieval Method Based on Cross-Hardware Platform Features
## 3 Methods
### Decoding Analysis  
The decoding difference will significantly affect the quality of feature extraction. The quantization matrix, HUFFMAN table, and DCT/IDCT process used by different JPEG codecs are not exactly the same, and the output codec results are often different. This paper mainly compares the decoding hardware capabilities.  
The Turing-based NVIDIA Tesla T4 supports HEVC 4:4:4 (8/10/12 bit), H.264, HEVC 4:2:0 (8/10/12 bit), VP9 (8/10/12 bit) and other video decoding formats. In addition, the JPEG decoding of the TeslaT4 chip supports the maximum resolution of the input image, 32,768 \(\times\) 16,384, and the minimum resolution, 64 \(\times\) 64 [7,8].  
For Atlas 300V, the JPEG input image maximum resolution is 8192 \(\times\) 8192, and the minimum resolution is 32 \(\times\) 32. When the Atlas 300V implements the JPEG image decoding function, it only supports Huffman encoding. The color space of the original image before compression is YUV, and the ratio of each component of the pixel is 4:4:4, 4:2:2, 4:2, 4:2:0, 4:0:0, or 4:4:0. Arithmetic encoding, progressive JPEG format, and JPEG2000 format are not supported. In addition, the Atlas 300V supports a maximum of four Huffman tables on hardware, including two direct current tables and two alternating current tables. Ascend supports 3 quantization tables, 8-bit sampling accuracy, and decoding of sequential encoded images. Also, it supports JPEG format decoding based on discrete cosine transform (DCT) and supports image decoding with a start of scan (SOS) flag. Video decoder (VDEC)only supports decoding of input streams by frame. If there are bad frames or missing frames in the code stream, the decoder VDEC will mark the frame as a decoding failure and report an exception. Through the interlacing mode encoding out of the stream, VDEC only supports decoding H264 8-bit encoded stream. At the same time, it can achieve the purpose of fast decoding and fast output, but this scenario does not support decoding the code stream containing B frames [17; 54].  
Due to the limitations of the hardware of various manufacturers, the pictures and videos of many scenes could be directly decoded successfully. By analyzing the image decoding failure, we found that a few of the image decoding failures were due to an image format error, and the image is opened and presented as black. Most of the image failures were caused by image resolutions, width and height alignments, image memories, etc., that do not meet the hardware platform. Other image-decoding failures are due to the limitations of the hardware itself, resulting in inconsistent images successfully decoded on both sides.  
In order to reduce the difference in decoding, we first compared the differences between hardware-platform decoding and CPU software decoding. Specifically, the same images and videos were decoded through different decoding modules to obtain their respective YUV images, the absolute value of the difference between the two was calculated pixel by pixel, and then the number of current differences was calculated, respectively, according to the absolute value of the pixel difference. Next, we chose the software decoding mode with the closest precision to the hardware decoding and executed the software decoding directly after the hardware decoding failed. In addition, we transplanted the different modes of hardware decoding and software decoding (such as the 3 DCT/IDCT modes in Turbo jpeg) into the software decoding, using the same DCT mode, so as to achieve the same codec results. Finally, we added a color-space conversion module to convert input formats not supported by the hardware pre-processing module to formats it supports (such as YUV444 to YUV420), so as to further improve the image utilization.