私はプロジェクト、「リモート デスクトップ コントロール」という名前のクライアント サーバー アプリケーションに取り組んでいます。私がしなければならないことは、クライアント コンピューターのスクリーン キャプチャーを取得し、このスクリーン キャプチャーをサーバー コンピューターに送信することです。おそらく、1 秒あたり 3 ～ 5 枚の画像を送信する必要があります。ただ、直接送るBufferedImageと処理にコストがかかりすぎることを考えると、画像のサイズを小さくする必要があります。画質はロスレスである必要はありません。
画像のバイトサイズを減らすにはどうすればよいですか? 助言がありますか？
ソケットの反対側でGZIPInputStreamとそれに対応する出力を使用することで、非常に簡単に ZIP で圧縮できます。
編集：
また、送信用のデルタイメージを作成できることに注意してください。たとえば、「透明な色」(マジック ピンク #FF00FF) を使用して、画面のその部分に変更が加えられていないことを示すことができます。反対側では、これらの魔法のピクセルを無視して、最後の画像の上に新しい画像を描画できます。
画像に既にこの色が含まれている場合は、実際のピンク色のピクセルをたとえば #FF00FE に変更できます。これは目立たない。
もう 1 つのオプションは、すべての画像で1 ビット マスクを送信することです (変更のないピクセルを任意の色にペイントした後)。ハフマンコーディング）。
a を使用する Vbence のソリューションはGZIPInputStream良い提案です。ほとんどの商用ソフトウェア (Windows リモート デスクトップ、VNC など) でこれが行われる方法は、スクリーン バッファへの変更のみが送信されることです。したがって、クライアントが「見ている」もののコピーをサーバーに保持し、連続するキャプチャごとに、画面領域の違いを計算します。次に、これらの画面領域のみを、左上の座標、幅、高さとともにクライアントに送信します。そして、クライアントの「ビュー」のサーバー コピーをこれらの新しい領域だけで更新します。
これにより、使用するネットワーク データの量が大幅に削減されます。この回答を入力している間、キーストロークごとに 400 程度のピクセル (20x20) しか変化しません。これは 1920x1080 の画面では画面の 1/10,000 にすぎないため、検討する価値があることは明らかです。
唯一の高価な部分は、あるフレームと次のフレームの間の「差」を計算する方法です。安価にそれを行うためのライブラリはたくさんありますが、それらのほとんどは非常に数学的です（離散コサイン変換タイプのもの、私の頭をはるかに超えています）が、比較的安価に行うことができます。
制御可能な圧縮/品質で JPG にエンコードする方法については、このスレッドを参照してください。左側のスライダーは、レベルを制御するために使用されます。
最終的には、ストリーミング可能なビデオ コーデックに画像を直接エンコードする方がよいでしょうが、詳細については少しわかりかねます。
1つの方法は、ImageIOAPIを使用することです
ImageIO.write(buffimg, "jpg", new File("buffimg.jpg"));
品質やその他のパラメータについては、よくわかりませんが、可能であるはずです。さらに深く掘り下げてください。