libvncclient: enhance tight decoder to support all 32bpp pixel formats#606
Open
jknockel wants to merge 2 commits intoLibVNC:masterfrom
Open
libvncclient: enhance tight decoder to support all 32bpp pixel formats#606jknockel wants to merge 2 commits intoLibVNC:masterfrom
jknockel wants to merge 2 commits intoLibVNC:masterfrom
Conversation
The tight decoder now supports the following 32bpp pixel formats in both big-endian and little-endian byte orders: ABGR, BGRA, ARGB, and RGBA. Prior to this change the supported 32bpp pixel formats were more limited and dependant on the requested byte order of the client's pixel format.
Prior to this change, the only 32bpp pixel formats that the tight decoder supported were the ABGR, BGRA, ARGB, and RGBA 32bpp pixel formats. This is because these are the only RGB formats that TurboJPEG can directly output. To support all possible 32bpp pixel formats with all possible maximums, shifts, etc., we need to perform additional conversion after decompressing the JPEG. Thankfully the 16bpp code path is already doing this, so we can reuse it if the client requests a 32bpp pixel format that TurboJPEG cannot directly output.
|
@jknockel: Have you progressed on your PR? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.