Bug: Wrong colours when viewing a TightVNC server

[logic]

For some time now (ever since I started using an UltraVNC client against a TightVNC server), I've been encountering problems with the colours. The server settings are as follows:

- TightVNC Server 2.0.3 ("built on May 27 2011 at 04:44:38").
- "Grab transparent windows" is enabled
- Screen polling cycle is 1000 ms
- Hide desktop wallpaper is enabled

The UltraVNC client settings are as follows:

- Auto select is disabled
- Encoding is set to anything other than "Hextile" or "Raw" (tried all encodings listed)
- Colour depth is set to Full Colors
- Use CopyRect encoding is ON
- Use Cache Encoding is ON
- Zip/Tight Compression is ON, level 6
- Jpeg (Tight) is ON, quality 6
- Track remote cursor locally is ON
- Viewer scale is OFF
- Server scale is 1/1

The remote host's configuration is as follows:

- Operating system is Windows 7 64-bit
- Video card is Radeon HD 5800
- Drivers are Catalyst 11.5
- Screen resolution is 1920x1200, 32-bit colour depth
- Aero is disabled, "Windows Classic" theme is selected.
- Desktop background is a solid colour: (58, 110, 165)

The problem that I observe is that sections of solid colour do not always encode properly. They appear to be treating pixels with the wrong byte order. The affected regions seem to be those that are free of any detail, but the exact criteria are not obvious.

The bug occurs frequently even in areas of the screen that are being used. For instance, if I right-click on a task bar button, the selected row of the resulting menu is likely to be partially miscoloured.

Here is a screenshot that demonstrates the problem:



The blue next to the console windows is the correct background colour (58, 110, 165). The tan/orange colour in the rest of the background area is colour (165, 110, 58), byte order flipped, and is wrong. Many other cases of incorrect byte order can be seen in the colour swatches in the Desktop Background dialogue.

When I connect with other VNC clients (tried RealVNC, TightVNC, the Java client supplied with TightVNC's built-in web viewer), this discoloration does not occur.

[jinnko]

I realize this post is very old, but I still found it high in the results on google, so here's the solution to this issue.

I have had this problem connecting from Chicken of the VNC on OSX to vncserver on linux. I found the solution to the problem hinted at in the tightvnc manpage under the pixelformat section.

The viewer can do the conversion to any other pixel format, but it is faster if the depth and pixel format of the server is the same as the equivalent values on the viewer display.

Therefore when connecting to a vnc server we should connect with the same setting between the client and server.

This works out as:

• if we choose --depth 8 on the server we should use "256 colors" on the client, or 8bit.
• if we start the server with --depth 16 --pixelformat rgb565 then we should select "thousands of colors" on the client, a.k.a. 16bit.
• if we choose --depth 24 on the server we should use "millions of colors" on the client, or 24bit.