8ビットピクセル用のtightvncの設定
私はtightvncを実行しています。サーバーとクライアントの両方で、-depth 8を使用しました。
それにもかかわらず、セッションを開始すると、クライアントのビューアプログラムがこの情報を出力します。これは、32ビットが使用されることを示しているようです。これについての説明はありますか？
VNC server default format:
8 bits per pixel.
True colour: max red 7 green 7 blue 3, shift red 0 green 3 blue 6
Using default colormap with is TrueColor. Pixel 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
サーバーとクライアントの両方でデスクトップバージョンのUbuntu10.10（Maverick）を使用しています。 TightVNCは両端がバージョン1.3.9です。新しいバージョンの2.xは、クライアントのJVMバージョンを除いて、現在のところWindowsのみであると思います。サーバー上の1.3.9と互換性があるかどうかわからないため、2.xでもあるクライアントJVMバージョンを使用していません。
呼び出しは次のとおりです。
vncserver -depth 8 -geometry 800x600 :1
vncviewer -depth 8 -noshared -nocursorshape 255.255.255.255:1
Psycogeekのおかげで答えは次のとおりです。
on vncserver use -pixelformat bgr233
on vncviewer use -bgr233
これらのオプションが追加されると、ビューアは8ビットピクセルを使用していると主張します。 -depth 8はフリーソフトウェアであるため、なぜ十分ではないのか、わざわざ質問するつもりはありません。
また、これを試してください：
on vncserver use -depth 32
on vncviewer use -bgr233
Psycogeekによって提案されているようにサーバーでbgr233を使用している場合、サーバーで実行されているアプリケーションはディザリングを使用して外観を改善することがあります。たとえば、KDEはこれを行います。ディザリングパターン、特に「誤差拡散」法によって生成された不規則なパターンは、十分に圧縮されず、伝送が遅くなります。
以下のKDEデスクトップでのテストは、サーバーがトゥルーカラーモードで実行されている場合、ネットワークを介して転送されるデータの量が最小であることを示しています（深度32、深度24も正常に機能する可能性がありますが、これはテストしませんでした）およびクライアントはbgr233色を要求します。次に、サーバーは色をbgr233パレットで使用可能な色に「丸め」、その結果、均一な領域が適切に圧縮されます。
Vncのバージョン、設定、および接続タイプによっては、圧縮されたssh接続を介してvnc接続を実行することも有利な場合があります。
ssh -C -L 5901:127.0.0.1:5901 user@remote
（vncviewerを使用してremote：1ではなくlocalhost：1に接続する）および/または「vncviewer-encodings」を使用してvnc圧縮方法のリストを調整する。
テスト
転送されたデータ量の統計を取得するには、-vを指定してssh-Cを実行します。これにより、ssh接続の最後（ctrl + d）に統計が出力され、vncによって送信されたデータの量と、sshがそれを圧縮できる量が示されます。
Vncサーバーで、OpenSUSE12.2の標準デスクトップを使用して1440x800でKDEを実行します。 OpenSUSEデスクトップの隅には、半透明の背景とグラデーションライト効果のあるデスクトップフォルダがあります。フォルダにはいくつかのアイコンが含まれています。さらに、起動パネルがあります。テストごとに、-C -vでssh接続を開始し、vncviewerで接続し、デスクトップが完全に送信されたら接続を閉じ、ssh接続をCtrl + Dキーを押して統計を読み取ります。ローカルホストに接続しているにもかかわらず標準のvnc設定を使用するには、-encodings「copyrecttight hextile zlib correrreraw」を指定したvncviewerを使用します。 2回目のテストでは、「タイト」を省略します。最後に、デフォルトのローカルホスト設定でもテストします。私はすべてのテストを無地のデスクトップの背景色で繰り返しますが、bgr233パレットで利用できる純粋な白や他の色ではありません。
結果
（1）Christoph Kummerによる背景画像「Evening」（OpenSuSE 12.2に同梱）：
「タイトな」エンコーディングの場合：
32 bit server + bgr233 client: raw data 231,129, compressed 231,195
16 bit server + bgr233 client: raw data 235,528, compressed 235,548
bgr233 server + bgr233 client: raw data 379,472, compressed 379,524
16 bit server + 16 bit client: crashes xvnc server
32 bit server + 32 bit client: crashes xvnc server
「タイトな」エンコーディングなし：
32 bit server + bgr233 client: raw data 514,614, compressed 336,993
16 bit server + bgr233 client: raw data 526,267, compressed 343,430
bgr233 server + bgr233 client: raw data 1,122,449, compressed 440,477
16 bit server + 16 bit client: raw data 3,422,711, compressed 1,486,065
32 bit server + 32 bit client: raw data 4,620,578, compressed 2,806,274
「localhost」設定の場合：
32 bit server + bgr233 client: raw data 1,153,388, compressed 231,740
16 bit server + bgr233 client: raw data 1,153,397, compressed 236,428
bgr233 server + bgr233 client: raw data 1,153,695, compressed 380,015
16 bit server + 16 bit client: raw data 4,612,015, compressed 1,166,199
32 bit server + 32 bit client: raw data 4,611,296, compressed 2,805,144
（2）無地の背景：
「タイトな」エンコーディングの場合：
32 bit server + bgr233 client: raw data 10,151, compressed 9,862
16 bit server + bgr233 client: raw data 14,994, compressed 14,817
bgr233 server + bgr233 client: raw data 76,335, compressed 76,268
16 bit server + 16 bit client: crashes xvnc server
32 bit server + 32 bit client: crashes xvnc server
「タイトな」エンコーディングなし：
32 bit server + bgr233 client: raw data 28,285, compressed 15,885
16 bit server + bgr233 client: raw data 40,597, compressed 25,410
bgr233 server + bgr233 client: raw data 460,902, compressed 93,067
16 bit server + 16 bit client: raw data 161,323, compressed 73,196
32 bit server + 32 bit client: raw data 152,342, compressed 78,657
「localhost」設定の場合：
32 bit server + bgr233 client: raw data 1,155,743, compressed 14,926
16 bit server + bgr233 client: raw data 1,153,388, compressed 19,015
bgr233 server + bgr233 client: raw data 1,153,379, compressed 77,238
16 bit server + 16 bit client: raw data 4,611,296, compressed 62,929
32 bit server + 32 bit client: raw data 4,611,296, compressed 74,081
ディスカッション
1440 x 800 = 1,152,000であり、4を掛けると4,608,000になることに注意してください。 「localhost」モードでは、vncは非圧縮データを送信しているようです。デスクトップの背景とサーバーの色深度の選択に違いはありません。また、vncは、16ビットモードでも送信に32ビット/ピクセルを使用しているようです。それにもかかわらず、sshがデータストリームをどれだけうまく圧縮できるかには違いがあります。
テストされたすべてのケースで、サーバーが32ビットカラーで実行されている場合、クライアント上のbgr233は最小量のデータを受信し、サーバー上でもbgr233を使用している場合は、16ビットカラーとはるかに大量のデータがそれに続きます。効果は、無地の背景で最も顕著になります。
画像の背景では、「タイトな」エンコーディングとlocalhost + ssh圧縮により、bgr233クライアントで同様の結果が得られます。これは、「タイト」がこれらの設定でzlib圧縮（sshが使用する圧縮と同様）を使用していることを示しています。
16ビットおよび32ビットのクライアント設定では、「タイト」を使用すると、残念ながらサーバーがクラッシュします。これらは、特に背景写真で、「タイト」でサポートされているjpeg圧縮が役立つ設定になります。
警告：結果は、ローカルホストのデフォルト設定でのssh圧縮がうまく機能することを示唆しています。ただし、このテストには、「copyrect」エンコーディングが重要になる可能性のあるWebブラウザで長いページをスクロールするなどの一般的なデスクトップの使用は含まれていません。
さらに、ssh圧縮により、高速接続で顕著な遅延が発生する可能性があり、その結果、優れた圧縮にもかかわらず接続が遅く感じられます。
-JJ