#2 screenshot of W2k has wrong colors

[Anonymous]

I used the following command:

spiro-lx1 ~ # vncsnapshot win2ksp3:0 /tmp/test.jpg
VNC server supports protocol version 3.3 (viewer 3.3)
No authentication needed
Desktop name "win2ksp3"
Connected to VNC server, using protocol version 3.3
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift
red 16 green 8 blue 0
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift
red 0 green 8 blue 16
Image saved from (local host) 1024x768 screen to
/tmp/test.jpg using 1024x768+0+0 rectangle

When I look at the file it generates, the colors are
all off. The output says something about shifting the
colors. I didn't see any params to turn such color
shifting off. I want to be able to capture the screen
w/ the original colors for comparison later on.

[Nobody/Anonymous]

[Grant McDorman]

Logged In: YES
user_id=178930

The messages about "shifting" the colours (colour mask) is
just reporting what the server says.

It sounds like the colour channels are wrong - probably red
and green switched.

This problem is most likely something odd with the VNC
server you're trying to get the snapshot from. What machine
(OS) is it, and what VNC server? If the name in your
message is correct, the server is Windows 2003; this is
unlikely to be the issue, though.

I do note that the server is behaving oddly - first it says
the red byte is first ("red 16 green 8 blue 0") and then it
says the opposite ("red 0 green 8 blue 16").

Note: please either include a contact (such as e-mail) or
create a SourceForge account and use that to submit items.
Without either, I am unable to contact you.

[Nobody/Anonymous]

Logged In: NO

Hi. Thanks for the response. My email is
spiro_kourtessis@yahoo.com.

It's actually red and blue that is being flipped. I have
verified that the issue seems to be the VNC server I am
working with, but it's a in house propriatery one that I
have to deal with. I can work with the developers here, but
I am hoping to find a workaround since as of today this has
become a high priority item for my team. The funny thing is
that if I use a regular vnc viewer to connect to the server,
everything looks fine.

I have looked at buffer.c and tried to flip the red and blue
values in BufferPixelToRGB and in AllocateBuffer (one at a
time), but I got other weird results (like part of the
screen changing colors while the rest doesn't, and neither
part looking right).

Can you explain to me why there would be two reports from
the server regarding the color shift? Is this why I am still
having a problem even though I flip the colors in buffer.c?
Given that a regular vnc viewer is able to display the
screens of the server properly, I am thinking this is a
common problem that vnc viewer is correcting. Any ideas to
point me in the right direction?

Thanks a lot for your help.

Spiro
spiro_kourtessis@yahoo.com

[Frediano Ziglio]

Had same issue with some vnc server.
It seems that vncsnapshot send some shifting that are not that likely accepted by server.
Note that blue and red in image are swapped.

From log you can see two lines
... shift red 16 green 8 blue 0 # server
... shift red 16 green 8 blue 0 # client
server seems to ignore client format request.

Note however that it would better if vncsnapshot request same encoding so server doesn't have to swap bytes but just do a copy.