The previous tight decoder was limited in that it only supported a few of the 32bpp pixel formats that TurboJPEG could natively output. This merge request enhances the tight decoder so that it supports all possible 32bpp pixel formats (all possible maximums, shifts, etc.).
This merge request is split into two commits. The first commit enhances the tight decoder so that it covers all four of the 32bpp pixel formats that TurboJPEG can natively output in either big- and little-endian byte orders. Prior to this commit the tight decoder only supported a limited number of the pixel formats that TurboJPEG could natively ouput and the formats supported were dependent on the client's requested byte order. The second commit further expands the pixel format coverage to perform additional conversion if the 32bpp format is not natively supported by TurboJPEG to cover pixel formats with arbitrary maximums, shifts, etc. Thankfully by necessity, since TurboJPEG cannot natively output 16bpp pixel formats, the 16bpp code path was already doing this very conversion, so we can reuse it if the client requests a 32bpp pixel format that TurboJPEG cannot directly output.
Note that this merge request does not change the handling of 16bpp pixel formats, which were already completely covered by the code previously.
The previous tight decoder was limited in that it only supported a few of the 32bpp pixel formats that TurboJPEG could natively output. This merge request enhances the tight decoder so that it supports all possible 32bpp pixel formats (all possible maximums, shifts, etc.).
This merge request is split into two commits. The first commit enhances the tight decoder so that it covers all four of the 32bpp pixel formats that TurboJPEG can natively output in either big- and little-endian byte orders. Prior to this commit the tight decoder only supported a limited number of the pixel formats that TurboJPEG could natively ouput and the formats supported were dependent on the client's requested byte order. The second commit further expands the pixel format coverage to perform additional conversion if the 32bpp format is not natively supported by TurboJPEG to cover pixel formats with arbitrary maximums, shifts, etc. Thankfully by necessity, since TurboJPEG cannot natively output 16bpp pixel formats, the 16bpp code path was already doing this very conversion, so we can reuse it if the client requests a 32bpp pixel format that TurboJPEG cannot directly output.
Note that this merge request does not change the handling of 16bpp pixel formats, which were already completely covered by the code previously.