Win7 UltraVNC Viewer with Linux vncserver :1 -depth 8 -cc 3

[jkmccarthy]

On my Windows 7 host, in VirtualBox I'm running a CentOS Linux VM to replace a Win7 / Linux dual-boot setup.

I have a Linux application "figdisp" developed long ago for use on a PseudoColor (depth=8) display, so my former dual-boot setup had two monitors configured as separate screens (not Xinerama), where screen :0.0 was TrueColor and screen :0.1 was PseudoColor ... when starting "figdisp", I would direct it to the :0.1 display screen.

Now on Linux under VirtualBox, I'm using the Linux vncserver to create a virtual PseudoColor display:

% vncserver :1 -name Figdisp -geometry 1912x1146 -depth 8 -cc 3

... that I can then view on my Windows 7 host's TrueColor display. When I run the "figdisp" application with -display 127.0.0.1:1 -etc, the application reports that it "Got 159 bitmap colors and 16 line-graphics colors in default color map" ... which is exactly as I expect (in the vncserver's display :1, I'm using mwm as a no-frills window manager, leaving 175 colors in the default color map unassigned until the "figdisp" application starts). Initially, figdisp assigns greyscale values to the 159 bitmap colors and displays a "test pattern" with these greyscale values running diagonally ... here is the Figdisp vncserver 127.0.0.1:1 display as viewed using Linux vncviewer on the local Linux VM:


(Click on the image above to view the native 1920x1200 pixel wuxga screen capture)

But when I close the Linux vncviewer and reconnect to the vncserver display using UltraVNC-viewer from the Win7 host computer, instead of rendering smoothly varying shades of grey, the UltraVNC-viewer shows distinct diagonal bands. I count only 32 levels of grey in the greyscale image rendered by UltraVNC-viewer (not the 159 bitmap colors that "figdisp" reserved in the default color map and is using to render the image).


(Click on the image above to view the native 1920x1200 pixel wuxga screen capture)

Is there a setting in UltraVNC-viewer on Windows that I can change that would force it to use all of the colors in the PseudoColor display's default color map when rendering this greyscale image ? The advantage for me of using a VNC-viewer running on the Windows host is that, if I have a second monitor, it's trivial to drag the Windows VNC-viewer application over to the second monitor, so that I can see both the Linux VM session (TrueColor) and the "Figdisp" (PseudoColor = vncserver :1 -depth 8 -cc 3) display simultaneously on adjacent screens, thus duplicating the functionality my previous dual-boot arrangement had when booted to Linux.

I've tried many of the "Format and Encoding" options available in UltraVNC viewer, but the banding of greyscale levels was similar in all those that I tried (including Hextile -- used by my Linux vncviewer -- and Raw, Ultra, and u2...), with and without checkmarks against Zip/Tight compression and Jpeg (Tight) Quality.

Before hunting-for and trying-out other Windows VNC-viewer applications, I thought I would post here to see if I just haven't found the right setting(s) for the Windows UltraVNC-viewer.

Thanks in advance,

--Jim

[jkmccarthy]

Just an update on my efforts over the last 3 nights to find a workaround:

• Since the PseudoColor image fidelity (and speed) of Linux vncviewer operating under X-windows inside my VirtualBox Linux VM were quite acceptable (and I was skeptical other Windows VNC viewers would be as easy to configure as UltraVNC's viewer), while waiting for my plea to be posted here I decided to investigate the option of running an X-server on my Windows host alongside VirtualBox, and directing the Linux vncviewer to that.


• Having read good reviews on-line about the speed and ease-of-use of the X-server VcXsrv, I decided to give that a try. The PseudoColor image fidelity was (not surprisingly) as good under VcXsrv on Windows as it was inside the VirtualBox Linux VM (and this solution would still allow me to move the VcXsrv display to a second monitor, which I've not been able to do completely inside VirtualBox -- I think because the Xorg version of my preferred Linux distro is too old) ... but unfortunately the speed was just not-quite-acceptable for my purposes -- i.e., running "figdisp". ((My reason for needing to maintain this X application on a depth=8 PseudoColor screen is that, by manipulating its display's Color Map, figdisp can *very* quickly (and interactively) modify the mapping between image-pixel values and the greyscale (or false-color) Color-Map entries assigned to them, *without* having to rescale all the image-pixel values and reload the updated values back into the display's image buffer. Hence "figdisp" is able (like I said, interactively and *very* quickly) manipulate the displayed image brightness and contrast (and where applicable, false-color mapping) ... for me it's been a really valuable 'quicklook' tool in conjunction with the acquisition of scientific imaging data, and figdisp also happens to be well-integrated into a data reduction toolkit of Fortran-77 analysis applications (dubbed "figaro"), originally developed at Caltech for ground-based optical astronomy)).


• So anyway, after similar sluggishness with another Windows-based X-server, I then did circle back to try a different Windows VNC-viewer -- TigerVNC -- that I found on-line here: https://bintray.com/tigervnc/stable/tigervnc/ ... in particular, I downloaded the executable called "vncviewer64-1.9.0.exe" (the most recent "stable" 64-bit TigerVNC viewer for 64-bit Windows). My initial results have shown me that the TigerVNC -viewer seems as responsive as the UltraVNC -viewer on my Windows 7 host, when used to view and interact with "figdisp" on a wuxga-size PseudoColor display created by Linux vncserver running inside a VirtualBox Linux VM. Meanwhile, the image fidelity of the TigerVNC -viewer is free from the distinct color-map "banding" issue that I encountered with UltraVNC. Here's a TigerVNC screen-shot for comparison to the 2nd screen-capture in my original post:

(Click on the image above to view the native 1920x1200 pixel wuxga screen capture)

Although this doesn't explain or resolve the depth 8 color map "banding" issue I ran into when I tried using the UltraVNC -viewer on Windows 7 for my very particular application here, my discovery that I can use the TigerVNC -viewer on Windows to give me both the speed and image fidelity required for this application means I'm now good to go with this configuration.

Should anyone be interested in digging into the cause (and remedy?) for the depth 8 color map "banding" that I encountered with UltraVNC's viewer (see again the 2nd screen-capture in my original post), I'd be curious to know the cause, but since I now have a workaround with another VNC viewer that works quite satisfactorily for me on Windows 7, happily I'm no longer in dire need of help with the UltraVNC issue displaying a PseudoColor vncserver screen.

Thanks for reading,

-- Jim