Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libvncclient: enhance tight decoder to support all 32bpp pixel formats #606

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jknockel
Copy link
Contributor

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 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant