スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

液晶ディスプレイの仕組み?

ふと、「1ピクセルってRGBのセル3つセットで成り立ってるんだよなぁ。なら、ピクセルをまたいでもRGBが連続して光ってさえいればそれは白に見えるんじゃないだろか?」と、思い、MSペイントで簡単に検証してみた。

■基本的な情報
・今現在の一般的な表示機器は、それぞれ自在に色を変化させることができる粒[ピクセル]の集まりでできている。
・一般的にピクセルは正方形で格子状に並んでいる。
・1つのピクセルは赤(R)、緑(G)、B(B)の3つの長方形を組み合わせてものである。
・RGBセルはR、G、Bの順番でピクセル内部に横1列に並んでいる。
・RGBセルは隙間なくびっちりならんでいるわけでなく、大体仕組みの問題で極小さな隙間があいている。

(255,255,255)はRGBすべてのセルが全開に光ってるから白色に見えます。
ならば(0, 255, 255)=水色,(255, 0, 0)=赤っていう2つのピクセルを並べて見てはどうでしょうか。
この2色をくっつけて縦線を描くと、画像の意味的には水色の線と赤の線っていう2色2本の線ですが、
表示機器からすると、RGBの順番に点灯しているか、GBRの順番に点灯しているかの違いしかありません。
(ただし、後者のBとRの間には、構造上1ピクセル内のRGBセルの間隔より広い隙間があると思われます。)


それを実際に再現してみたら次の画像のようになります。

色


緑から上の縦線の構造は以下の通り。
左から

1. (255,255,255)のただの白線(幅1ピクセル)
2. (0, 255, 255)と(255, 0, 0)の2色の線(幅2ピクセル)
3. (0, 0, 255)と(255, 255, 0)の2色の線(幅2ピクセル)
4. (255, 0, 255)のただの紫線(幅1ピクセル)
5. (0, 0, 255)と(255, 0, 0)の青と赤の2色の線(幅2ピクセル)

緑線以下は幅2ピクセルの線のみ左右の順番を入れ替えたものになってます。
(画像は必ず100%状態で表示してください。)


表示機器によりけりなんですが、
1,2,3は大体白に見えるはずです。
ただし、2,3は1よりも使っているRGBセルの間隔が均一ではないために、白線の両サイドに元の色が見える、みたいな状況かもしれません。
構成を左右いれかえると、あら不思議、完全に2色に見えます。
(上が2色に見える場合はBGRの順に1ピクセルが構成されているんだろうなぁ。)

それどころか、2色の間に黒線が見えるかもしれません。
2番の場合、左右入れ替えるとB,G,Rの順で0が並び、少なくとも1ピクセル分程度の大きさの黒色ができます。


4と5はGを使わなかった場合です。
白のときに比べて、4,5はほとんど同じに色に見えるかもしれません。
5番の両サイドに赤と青が見えるなんてことは少ないはず。

これは4のただの紫線の時点で間にGセル分の隙間が開いているせいと考えられます。
5番は使っているBとRのセルの間にピクセルの境界があるので、その分離れています。
つまりどっちもRとBのセルの間に隙間があるわけで、これが大体同じの表示機器の場合、この2つは同じに色に見える、というわけですな。

5番の左右を入れ替えると白色の場合以上の黒色の隙間ができるため、決して紫線と同じもののようには見えないはずです。



これがわかったところで、で?って感じですが、、、この1/3ピクセルの単位を使ってなんかできるかもしれません。

スポンサーサイト

モニター選択画面

iPhoneアプリ

マルチモニター環境に対応すべくiPhone側のモニター選択画面作ってました。
出来は画像の通りで、Safariのタブ選択画面っぽい感じにしてみました。
見た目通りに真ん中に来てるモニターが選ばれて、完了を押すとその画面のリモートに切り替わります。
それぞれのサムネイルは静止画ではなくカクカクではあるものの定期的に更新される動画になっています。

Safariの場合は選択するとサムネイルが画面のサイズに拡大されて、ブラウザにスムーズに切り替わりますが、今回のこれはそうはなっていません。というのも、サムネイルが常に画面全体を映してないとだめなわけで、常に画面全体を写しているわけではないリモート操作時の画面とスムーズに繋げられないからです。この選択画面に入るときに操作画面を急速縮小するっていう手がありますが、多分見た目的には微妙です。

サムネイルがやや小さく見えるのは、サムネイルの最大縦横を固定しているからで、最近の横長モニターを表示するとどうしても横長になってしまいます。最大縦横が固定ってことからサムネイルの大きさは実際のモニター解像度に依存してません。この画像でいうと左のモニターの解像度は1920x1080ですが、右のは1280x800なんですが、右の方が幅固定の影響で大きく写っています。もっと解像度比を見た目で表現できればよかったんですがいいアイディアが出ず。
同じくこの画面では各モニターのピクセル的なつながりも表現できていません。プライマリモニターが実はセカンダリモニターの右にあっても、この表示になってしまいます。

モニターを実際の大きさ比で、実際の配置にならべて表示するようにしたほうがよかったかなぁ。。。


■技術的なこと
この画面はOpenGLでごりごり書いたりせずに素直にUIViewとかで作ってます。
サムネイルはUIImageViewで出していますが、問題は影。
UIViewのCALayerで影を出すってのを横見ますが、この方法を使うと激重になります。
考えれば当然で、Viewの描画のたびに影の形状を再計算しているんでしょうから、そりゃー重い。
そこで私の場合は、Quartzで影を描いたUIImageを作ってそれを表示しています。
そうすれば重いのは最初の一回だけで、以降は画像の表示だけになるんでサクサク動作になります。
(他に影を高速描画するって方法あるのかなぁ。知らないだけの可能性が高いか。)

QuartzではUIGraphicsBeginImageContextで準備をし、取り出したcontextに描画した内容をUIGraphicsGetImageFromCurrentImageContextでUIImageにできるのでそれを使います。パスに沿って図形を描画する際に影を描画する機能があるので、かなり簡単に影を描けます。単純に画像なら透明度は保存されないんですけど、こうやると透明度付き画像としてUIImageが作られるので便利。

■苦労
苦労は描画部分ではなく通信部分でした。
TCPの接続一本をリモートの画像取得とサムネイル取得を切り替えて使うわけですが、サムネイル画面への遷移はユーザー操作なわけで、レスポンスを遅らせるわけにはいかずに、即遷移させます。
つまり遷移時に前の通信の最中である場合があり、見た目とは別の部分の通信をしていることがあるというわけです。この画面を閉じるときはViewのメモリが開放されたあとに、通信が完了してデータがやってくる場合もあるので、一歩間違えればエラーで落ちてしまいます。内部で待たせたりしても、デッドロックの危険が出たりとなかなかに厄介。さらには通信が不安定な3Gでの動作も考えると、、、
ただでさえ通信とか描画などスレッドがある上に、Viewも複数あると頭がついていかなくなりますね。。。

iPhoneリモートはじめました。

iPhone用リモートアプリはじめました。
おもにTwitterで開発記を書いてましたが、せっかくなんでブログでもいろいろ書いてみたいと思います。

完成予定のリモートアプリの概要をまず。

■表面的な概要
・独自方式のリモートデスクトップアプリ(VNCやRDPとは互換性なし)
・Mac、Windows両対応
・部分最大30fpsの高速画面更新
・44.1kHzステレオの高音質低遅延な音声転送
・AES128bitの暗号化通信
・マルチディスプレイ環境への対応
・画面上でカーソルを動かすトラックパッドモード、Safariのようにタップした場所でクリックされるタッチスクリーンモードの2通りの操作方法
・iPhoneのIMEを使って文字を入力する方法、キーボードの入力をそのままPCに伝える方法の2通りの入力方法
・shift、alt、controlといった代表的な修飾キーや、F1~F12、tab、esc、半角キーなどの特殊キーが入力可能

といった具合になっています。
基本的にRDPアプリにありがちな機能をほぼ網羅しているはずです。

■技術的な細かいこと
・画面キャプチャーはWindowsではBitBlt、MacではCGDisplayを使用しています。
 ・Windowsはすべてのレイヤーをキャプチャーするので、高速キャプチャー時、PC側のカーソルが点滅します。
 ・MacはOpenGLによるキャプチャーの方が数段高速に動作しますが、OSX Lionで使用できなくなりました。
・3G、WiFi両対応ですが、回線の応答速度の都合上3Gでは部分最大7fps程度が限度です。
・部分最大30fpsは画面全体が30fpsでキャプチャーできる性能があること、iPhoneとPC双方で30fpsで処理しきれる範囲である必要があります。(PCとiPhoneのハード性能の向上で30fpsがでやすくなります。)
・画像形式にはjpegを利用しています。(内部にはRGB565のオプションが残っていますが。。。)
 ・サーバー側ではlibjpeg-turboを、クライアント側ではARM NEONを使用できるように独自に改造したlibjpegを使用しています。
 ・画質は4段階用意しています。(画質20~80)
 ・グレースケールはありません。
 ・動画性能の向上のために、動きの強い部分は解像度を半減させています。負荷低減により、ウィンドウのドラッグなどもスムーズに表示されます。
 ・広範囲の30fpsはこの機能によるところが大きいですが、オフにすることもできます。性能によりますが、オフの場合でも20fps程度はだすことができます。
・音声はiRemoteで使った携帯電話用ADPCMコーデックをそのまま利用しています。
 ・AACより独自でADPCMをエンコード、デコードした方が低遅延で動作するようです。
 ・内部ではPCMをストリーミング再生しています。
 ・モノラル、ステレオはもちろん、音質も11kHz、22kHz、44kHzと変更できます。
・タッチスクリーンモードはiPhoneでよくみるUIScrollViewとほぼ同様の挙動をします。
 ・UIScrollViewは動作重かったので、OpenGLを使い挙動を極力似せた独自のViewを使用しています。
・トラックパッドモードではカーソルがPC側カーソルと同じ画像がiPhone側でも表示されます。
 ・カーソルの動作は指の動く速度により加速度がかかったような動きをします。
・操作方法によらず、タップでクリック、ダブルタップでダブルクリック、ロングタップで右クリック、タップからのパン操作でドラッグ、ピンチアウトで拡大、ピンチインで縮小です。
・ホイールの動作は2本指パンでは動作しません。
 ・ツールバーのホイールボタンを押すことでホイール専用の操作モードになります。
 ・ホイールモード中は指の移動量がそのままホイール回転量になります。(指にスクロールが追従します。)

いろいろ書きましたが、独自満載でえらいことになってます。
ただし、操作方法、表示はiPhoneらしさということを最重要に考えて作っているので、いうほど独自性は感じ無いはずです。ツールバーもオーソドックスに下部配置でボタンも5つしかありません。ごちゃごちゃとボタンだらけだったり、iPhoneでは見慣れないような仕組みを使ってツールバーを出し入れしたり、複雑なジェスチャーをつけたりはしないようにしています。

そんなこんなで目指すところは、最高にオーソドックスでありながらあらゆることが簡単にできる。です。

進捗状況は現在70%程度で、完成は11月下旬、公開は12月程度を予定しています。
今後はちょくちょくブログで各機能について書いていきますんで、どうぞよろしくお願いします~。
Go To 物置。
プロフィール

書いてる人:つん

まったりのんびり。書いてる人の息抜きブログです。

多分連絡先↓
metal_tsun@yahoo.co.jp

カテゴリー
リンク
月別アーカイブ
バロメーター
Java歴:2005年2月から今まで。
3DCG歴:2005年8月から数年。
C歴:2006年4月から今まで。
VB歴:2007年3月からちょっと。
Delphi歴:2007年3月からちょっと。
PIC歴:2007年5月から数年。
イラスト歴:2007年12月から今まで。
DTM歴2008年2月からちょっと。
PHP歴2008年4月からちょっと。
C++歴2008年4月から今まで。
C#歴2009年1月から今まで。
Objective-C歴2009年4月から今まで。
CSS歴2012年5月から今まで。

ブログ開始日2005/10/11


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。