日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

<< 過去

白黒だとTIFFなわけ

職場の複合機はスキャナとしても使うことができる。

うちの職場ではスキャンデータを自分宛にE-mailで送る方法で使うことが多いが、

データを複合機に蓄積して、後で取りに行く方法もあるんだそうで。


スキャンデータの形式はPDFが標準だが、画像データとして編集したい場合もある。

そういう場合には他の形式を選ぶわけだが、その場合に選べる選択肢は「TIFFまたはJPEG」である。

なんでTIFFまたはJPEGなのか、最近までよくわかっていなかったのだが、

どうも 白黒2階調 の場合はTIFF、グレースケールまたはカラーの場合はJPEGという意味らしい。

グレースケールまたはカラーの場合のJPEGはよくなじみがあるから何も問題ないが、なぜ白黒の場合はTIFFが選ばれるのだろうか?


TIFFというのは、数ある画像ファイルの形式の中でも特に古いものである。

Windowsより昔からあり、Windows Bitmap形式ができる以前はWindowsの標準画像形式はTIFFだったんだとか。

このTIFFという形式は拡張性が高く、複数の画像圧縮方式を選択できる。色数なども細かく選択できる。

もっともWindowsのペイントでTIFFで保存すると無圧縮で保存されるなど、無圧縮という選択肢もあるのだが。

現在主流の画像ファイルの形式は JPEG, GIF, PNG など圧縮方式とファイル構造が一体となったものだが、

特定のファイル構造が決まっていない圧縮方式ではファイル構造にTIFFを使うことがよくあるようだ。


それで白黒2階調でスキャンして得られたTIFFファイルの圧縮形式を調べてみると「ファクシミリ互換のITU-T Group4」とわかった。

どうもFAXの画像符号化方式らしい。確かにFAXって白黒だよなぁ。

FAXもいくつかの方式があるが、現役の方式としてはGroupe3(G3)とGroup4(G4)の2種類がある。

G3, G4はいずれも画像データを圧縮してデジタルデータとして電話回線で伝送する。

画像データを圧縮することで短時間で伝送できる。時間が短いということは、電話代も節約できる。

ここで使われる圧縮方式はいずれも2値画像に特化した可逆圧縮方式で、G3ではMHまたはMR、G4ではMMRが定義されている。

すなわちG4形式で圧縮されているということは、MMRということらしい。


それにしても、わざわざメジャーとは思えないG4 FAX方式を使っているのはなぜだろうか?

ファイル形式とデータ量について (Bunkyo Web Style)

典型的なA4の文書データを圧縮したところ、G4 FAX(MMR)形式では無圧縮データの7.4%まで圧縮できるとある。

これは汎用的に使われる可逆圧縮の画像形式であるPNGの13.6%と比較すると、半分程度のサイズで済んでいる。

PNGでは1画素の割り当てに8bit, 24bit, 32bitを選ぶことができるが、2階調でも1画素に8bit割りあてる必要がある。

その後に圧縮するといっても、もともと2値画像に特化した方式にはかなわないのである。

ましてや色数が多い写真を想定したJPEGでは、容量が大きくなる上に非可逆ということでろくな事がない。


ところで現役のFAX方式にはG3とG4の2種類があると書いたが、ほぼG3しか使われていない。

というのもG4はISDN回線専用の方式なので、一般の電話回線で使える方式としてはG3しかないのだ。

じゃあG4 FAX用の圧縮方式のMMRなんて使われていないんじゃ? と思ったんだが、そんなことはない。

ApeosPort®-VII C7773 / C6673 / C5573 / C4473 / C3373 / C2273 おもな仕様と機能  (FUJI XEROX)

複合機のファックス機能の仕様を見てみると、通信モードが「ITU-T G3」と書いてある一方で、

符号化方式に「MH、MR、MMR、JBIG」と書いてあり、G3で定義されている2方式以外にMMRとJBIGが書かれている。

どうもG3 FAXはいろいろ拡張されていて、スーパーG3と言って、伝送レートの高速化や、圧縮方式の追加が行われている。

送受信の両側とも対応していれば、伝送レートを高くしたり、高圧縮な方式を選んで、時間と電話代を節約する。

ちなみにJBIGも2値画像の圧縮方式で、MMRよりさらに高圧縮らしいが、対応している機器は限られるようだ。


MMRよりはJBIGの方が高圧縮とはいうが、これをTIFFに格納して使おうということはあまりないようだ。

それに次いで高圧縮なMMRはTIFFに格納して使われることはそれなりにあるので、Windowsでも表示には対応している。

マイナンバーカードの券面事項確認APでは氏名・住所などを画像データとして格納しているのだが、形式はMMR圧縮したTIFF画像らしい。

2値画像の形式としてもっとも高効率な方式と考えているのだろう。ちなみに顔写真(グレースケール)はJPEG 2000で格納されているそう。

ただ、生成できるソフトウェアはあまり多くない。無圧縮のTIFFならWindows標準のペイントでもできるけど。

Webでも使われないようで、WebブラウザはTIFFの表示には対応していない。

なかなか限定的にしか使えない方式だが、2値画像に限れば最強の方式のようだ。


Author : hidemaro
Date : 2019/02/06(Wed) 23:27
コンピュータ | Comment | trackback (0)

ディスプレイ接続いろいろ

先日、Windows 10のデスクトップPCがレンタル業者から届いた。

届いてまず思ったのは起動がむちゃくちゃ速いこと。

どうも、SSDになったみたいね。今どきはこうだよね。


Windows 7時代のPCでは、メインディスプレイはDisplayPortで接続、サブディスプレイはDVIで接続していた。

サブディスプレイは職場に浮いていたディスプレイをもらってきたありあわせのものである。

これがWindows 10のPCになって、メインディスプレイはHDMI接続に変わった。

さらにPC側の出力は全てMini DisplayPortで、これを付属のアダプタで適宜変換するようになっている。


そもそも、ディスプレイの接続方式は古くはアナログのVGA方式が使われていたし、

今ももっとも無難な接続方式として共用のプロジェクタなどではよく使われている。

一方でデジタル接続方式として、もっとも最初に普及したのがDVIである。

もっともDVIはデジタルもアナログも兼用にできるので、コネクタ形状の変換でVGAにすることもできる場合がある。

実際、Windows 7世代のPCには付属品として、DVI-VGA変換アダプタが添付され、これでDVI出力にVGAのディスプレイを接続することもできた。


HDMIはDVIの形状違いに近いが、音声が伝送できたり、著作権保護機能が定義されている点が異なる。

AV機器の接続を想定した規格だが、PCのディスプレイ接続にもよく使われている。

DVIに比べればコンパクトだし、AV機器ではよく普及した規格ですからね。実際、家のPCはHDMIでテレビと接続している。

一応HDMIとDVIは相互に変換が可能となっている。ただし全ての機能が使えるとは限らず、互換性に問題がある場合もあるが。

一方のDisplayPortは本来はDVIとは伝送方式が異なる。

高解像度・マルチディスプレイに対応できる高速伝送を実現しており、まさに次世代のディスプレイ接続方式というにふさわしいのだが……

ただ、そのためには入出力ともにDisplayPort対応している必要がある。

特に表示側は対応機器が少ないので、DisplayPortの出力機器の多くはHDMI・DVI互換モードを備えている。

DisplayPortの物理層にHDMI・DVIのデータを通す機能で、この場合はコネクタ形状の変換でHDMI・DVI出力ができる。


以上のことから、DVIとHDMIはほぼ相互変換可能、DisplayPort→HDMI, DVIはほぼ変換可能ということになる。

さらにHDMI, DisplayPortからアナログのVGAへの変換器も販売されている。

これは変換器内部でデジタル・アナログの変換を行っているので、単なる形状変換ではない。


Windows 7世代のPCは。DisplayPortとDVI接続が1つずつあった。

これに対して付属品のディスプレイはDisplayPortまたはVGA接続だった。

PCには DVI-VGA変換, DisplayPort-DVI変換, DisplayPort-VGA変換 の3つのアダプタが添付されていた。

何を想定しているのかよくわからないが、付属のディスプレイとの接続にはアダプタは不要なので、それ以外のケースを想定しているのだろう。


これがWindows 10のPCはMini DisplayPort出力が複数あって、これに対して付属品のディスプレイではHDMIまたはVGA接続になった。

同じメーカーなんだけど、なぜかDisplayPortからHDMIに変わった。気まぐれなもんだなぁと思ったが。

それに対応して、Mini DisplayPortとHDMIの変換アダプタが1つ添付されていた。

他にMini DisplayPort-VGA変換アダプタが1つ、そしてMini DisplayPortの出力数と同じだけDisplayPortとの変換アダプタが添付されていた。

なんでそんなにDisplayPortとの変換アダプタが必要なのかはよくわからないが。

複数のディスプレイを使うとしても、DisplayPortのディスプレイがそんなにあるところなんてあるんかね。


ここで困ったのがサブディスプレイとの接続である。

従来はDVIで接続していたが、新PCにはDVI出力がないばかりか、DVIへの変換手段が提供されていない。

逆にディスプレイもDVI入力しかない。意外にもアナログ入力がないのだ。こりゃ驚いた。

一方で、旧PCの添付品にはDisplayPort-DVI変換アダプタがあったので、これを暫定的に使っているのだが、まもなくレンタル業者に返却することになる。


というわけで、DisplayPort-DVI変換アダプタを購入してもらおうと動いている。

値段自体はさほど高くないし、この程度なら今期中に購入できるのとのこと。

職場内に同じことになっている人がいるので、まとめて購入するつもりだ。


職場の半分以上の人がサブディスプレイを使っているのだが、2台目のディスプレイはありあわせのものなので人によっていろいろ。

自社製品の分解したディスプレイを使っている人もいて、あまり見た目はよくない。

自分の使っているのは見た目はそんなに悪くないが、これも何かの流用品で、DVIが唯一の入力なのもそれが関係あるかも知れない。

レンタルPCを借りる方法で2台以上のディスプレイを借りることもできるのだが、そうやっている人はさほど多くない。

レンタル業者から借りるメリットは、ものが確かなことと、故障時に早急に対応してくれること。でも、毎月お金はかかる。

メインディスプレイが使えなくなると問題なのでレンタル業者から借りるべきだが、サブディスプレイはそこまででも……という考えはある。

サブディスプレイの効果について合理的に説明しにくいという考えもあるのかもしれない。

リモートのワークステーションをよく使う人にとっては、リモート画面を表示するのに便利とか言えるけどね。


一方でレンタル終了時にディスプレイをレンタル業者から買い取ることができるようだ。話によればかなり安いらしい。

近くの人が「サブディスプレイが欲しい」と言っていたのだが、2台目を借りるところまではなかなか踏み出せていないようだった。

そこで、これから返却するWindows 7のPCのディスプレイを買い取るという選択肢もあるのでは? と言うと「それだ」ということで動き始めている。

ディスプレイを返却すれば処分方法は考えなくて良いが、買い取ると使わなくなったときに会社責任で処分しないといけないが、

購入代金自体も安く、おそらく長く使えるだろうから、サブディスプレイの目的にはちょうどよいだろう。

これからWindows 7のPCの返却が続くので、これがサブディスプレイの環境も改善する糸口になればよいが、さてはて。


Author : hidemaro
Date : 2019/01/30(Wed) 23:11
コンピュータ | Comment | trackback (0)

ネットワークスペシャリストの要求は高い

今日は情報処理技術者試験の日、というわけでネットワークスペシャリスト試験(NW)を受けてきた。

応用情報技術者試験(AP)(2016年春合格)→エンベデッドスペシャリスト試験(ES)(2017年春合格)を経てのNW試験である。

AP合格でESの午前I試験を免除されたが、今回もES合格でNWの午前I免除を受けている。

というわけで、10時半ごろに会場に着いて、午前II試験からスタート。


午前II試験は25問の4択問題が並んでいるもので、試験時間は40分と短い。

ただ、途中退出もできないので、どうしても最後までいる必要があり、その後は昼休み1時間を挟んで午後の試験になる。

昼休み1時間といっても、20分前には席に戻るようにというから、そんなに余裕はない。

というのは、ES試験のときにも思ったことだが。

そんな試験だが、最大で30分の遅刻まで許容されていて、25分ぐらい遅刻して入ってくる人がいた。

もちろん午前II試験の遅刻ということは、午前I免除者だろうけど、わずか15分ほどで解いたということだろうか。

その気になれば15分でも解ききれそうではあるけど。


午後I試験、午後II試験はともに記述式で選択した問題を回答する。

午後I試験の手応えがあまりよくない。午後II試験は意外と答えられた。

午後の試験を通じて思ったのは、ネットワークと一言でいうけど、いろいろな切り口があるということだ。

OSI参照モデルでネットワークは7層に分けられているけど、レイヤーの違いというのも切り口の違いの1つだ。

ネットワークの実務経験がある人でも、自分があまり関わったことがない分野の問題は難しいだろうなと。

午後I試験は3問中2問選択、午後II試験は2問中1問選択だから、選択制といってもそんなに選べるわけでもない。

そう考えると、問題との相性というのもあるのかもなぁと。

合格ラインが6割だから、取れている可能性もなくはないが、ちょっと厳しいかもねぇ。


NW試験の勉強をして学んだことは多い。

いろいろなタイプのネットワーク構成とそのための技術を学ぶことができた意味は大きい。

ただ、本来は実務経験の豊富な人のための試験ですからね。要求水準は高いなとも思った。

というか、NW試験って受験者多いのもあるけど、合格率13.6%(2017年実績)ですからね。

ES試験は受験者少ないけど合格率17.9%で、高度試験の中では一番高い。どんぐりの背比べかもしれないけど。

ネットワークに関わる技術者を広く対象にしているが、その要求水準は高いってことですね。


というわけで、不合格になったとして再挑戦するかというと微妙。

受験に向けて勉強したことで今の僕にとっての目的はほぼ達成したのでは? と。

今回はES合格で午前I免除になったけど、次回は免除にならないのもある。(次回春の試験まではES合格が有効だが、NWは秋だけの試験)

午前I試験はAP試験相当の範囲だから復習すれば問題なく通るはずだけど。


逆に合格したとして、この先はどうかというと、自分の分野に関わりが深いのがシステムアーキテクト試験だが、

これは午後II試験が小論文で、自分がシステムアーキテクトとしてやってきたことについて解答しなければならない。

僕の目指す道ではあると思うけど、すでにシステムアーキテクトである人のための試験で、これを目指す人の試験ではないなと。

情報処理技術者試験もいろいろあるんですよ。どれも広く言えばIT技術者向けだが、いろんな立場を想定しているので。


Author : hidemaro
Date : 2018/10/21(Sun) 22:59
コンピュータ | Comment | trackback (0)

タブレットがないのは不便だった

引越まで1週間ちょっと、というわけでやや使用頻度の低いものを整理したり、掃除をしたりしている。

順調といってよいと思うが、めんどくさそうな食器類は直前まで梱包できないので。

どこまで先行して着手できるかってことですね。

というか、冷蔵庫の中身も運べるように整理しないといけないんだよなぁ。うまく調整しないと。


この前、関西に行ってたときに、実家にタブレットを忘れてきてしまった。

次回行く予定はあるが3ヶ月後なので、そこまでタブレットなしっていうのもなぁ。

ということで、送ってもらうことにして、今日に無事に届いてやれやれと。

両親には手間をかけてしまったけどね。


タブレットがなかったn5日間だけでも、けっこう不便だった。

従来、タブレットでやっていたことを、スマートフォンでやればよくて、

どちらもAndroidだから機能的な差はあまりないはず。

画面の大きさの差、そしてタブレットとスマートフォンを別々に使えない不便さが目立った。


よく考えてみると、僕にとってはスマートフォンよりもタブレットとの付き合いの方が実質的には長い。

厳密に言えば、Windows Phone、X01Tを2007年から約5年間にわたって使っていたのだが、

この当時、スマートフォンという言葉がやっと出てきたばかりで、通信機能付きPDAぐらいのイメージで、

通信料の問題もあって、あまり通信を使わずに使っていた。PDAと電話がくっついているだけという感じ。

2013年、大学院入学を前にして、EMOBILE(当時)とモバイルルーターを契約し、これと併用するためにNexus 7を購入した。

ここから5年以上、端末は変わりつつも、一貫してAndroidタブレットを使ってきた。

このとき、一旦スマートフォンをやめて、音声端末に移行したのだった。


スマートフォンとタブレットの併用になったのは2017年の正月から。

当時の悩みは2つあって、1つは当時使っていたBB.exciteモバイルLTEの回線品質が良くなかったこと。

もう1つはゲームを遊ぶには安物のタブレットでは厳しかったこと。

この問題を一挙に解決するため、Y!mobileに電話もデータも集約し、新しいスマートフォンを買うことにしたのだ。

Y!mobileを選んだ理由はいくつもあるけど、決め手の1つはテザリングが定価で無料であること。

タブレットと併用するのは必須条件で、タブレットやPCを接続しても料金が高くならないというのは非常に重要な条件だった。


スマートフォンとの併用になって、ゲームは全てスマートフォン側に集約したり、

タブレットを買い換えるときに従来の7インチから8インチにやや大きくしたりという変化はあったが、

タブレットの使用頻度が大きく減るということはなくて、新聞や電子書籍を読む用途ではむしろ活躍が増えている。

ゲーム、音楽、外出時の調べごとを除いては、あまりタブレットの出番は変わっていないよね。

Androidが2台体制になって、スマートフォンでゲームの画面を出しながら、タブレットでWebサイトを見たり、2台同時に使うことも出てきた。


というわけで、スマートフォンだけになると、画面小さいなとか、1台だけじゃ不便だなってなるんだよね。

画面小さいということについては、タブレットとの対比で小さめの端末を選んだというのもある。

5.0インチのスマートフォンというのは、今では小さいんだよね。選択肢が少ないというほどでもないが。

もし1台で済ませるならば、もう少し大きな画面の端末の方が便利なのかも知れないとは思った。

世の中そういう考えが一般的ということなのかな。


安物のタブレットだから、性能が出ないのは悩みなんだけどね。

それでも画面が多少大きい方が役に立つというのはある。実際、ある程度の性能が出れば困らないしね。


Author : hidemaro
Date : 2018/08/11(Sat) 22:32
コンピュータ | Comment | trackback (0)

Androidに画面を転送できる

来週は夏休みなのだが、一方で社宅関係の手続きが動く可能性もなきにしもあらず。

必要な書面は送ってあって、抽選日は夏休み明けなので、一見問題ないのだが調整が必要になる可能性がある。


ただ、在宅勤務のためにリモートアクセスできますからね。

給与明細の確認などのためにリモートアクセスを業務外で使うことがあるけど、便利ですからね。

というわけで夏休みでも社宅関係の連絡を確認することはできる。

しかし、問題があって、それはこの期間の平日はずっと旅行で家にいないということ。


そういえば、リモートアクセスってAndroidでも使えると書いてあった覚えがあるし、

リモートアクセスで使えるアプリにモバイル用のメーラーらしきものがあった。

これがうまくいけば旅行先から会社のメールを確認できるのでは? ということで試してみた。

リモートアクセスの画面転送を受けるためのアプリをインストールして、

Webサイトからログインして、ログイン後に起動するアプリを選ぶと画面が転送されてくる。AndroidでもWindowsとあんまり変わらんな。


それで、モバイル用のメーラーらしきアプリの画面を転送してくると、

おー、スマートフォン向けの画面に最適化されたメーラーが立ち上がった。日本語のフォントがちょっと不格好だけど。

あとメールの入力時に、文節を確定するまで文字が表示されないというところも違和感がある。

Androidの場合は、ローカルで漢字変換までやって、確定させたら漢字の状態で転送されるようになってるみたい。

Windowsからだと、キーボードで打ったものがそのまま転送され、社内のMicrosoft IMEで漢字変換されるんだけどね。

ここら辺はリモートアクセスらしい挙動だが、モバイル用メーラーを使う限りにおいてはAndroidからでも使いやすい。


このリモートアクセスは社内に設置されたWindowsマシンで動いているアプリの画面を転送しているだけなので、

リモートアクセスで使えるどんなアプリの画面でもAndroidに転送することができる。

なので、Microsoft Outlookの画面をAndroidに転送して、メールの送受信を行うことも出来る。

ただ、やってみたけど、すごい操作しにくいんだよね。小さなタッチパネルで操作するには不便だ。

というわけでモバイル用メールアプリの有効性がわかった。

このモバイル用メールアプリもWindows上で動作して、その画面を転送しているだけなんだけどね。


営業の人とかが社外でメールの送受信するときはどうしてるんだろうね。

確かにこの方式でいいんだけど、ログイン手順が煩雑なので、正直めんどくさい。

別にAndroidだからという話ではなくて、Windowsからでもめんどくさい。ちょっと手間のかかる認証手段なので。

調べたところ業務用のスマートフォン・タブレットの場合は、一定のセキュリティ対策をすれば、OSのメーラーで会社のメールが読めるようだ。

だから、もともと出張が多い人はこの方法で対応しているのだろう。

一方で、リモートアクセスの画面転送方式であれば、セキュリティ面の懸念が小さいので、特段の制限はない。私物の端末を使っても問題ない。

業務用のスマートフォン・タブレットを使う場合でも、使用頻度が低い場合はこちらを選ぶ可能性はありそう。(共用の場合など)


というわけで、週の中間ぐらいに一度チェックして、社宅関係の情報があったら確認するようにしようかなと。

仕事の話は無視しとけばいいわけだけどね、(どうせ緊急の連絡なんて入るわけがないし)

こういうことができてしまうのも、在宅勤務制度のおかげなので、ありがたい話ですけどね。

出張や私用(給与明細確認など)のような在宅勤務以外で使うことの方が多いっていうね。

在宅勤務でも使ってるけどさ。今まで1回だけだけど。でも来月またやる予定だし。


Author : hidemaro
Date : 2018/07/04(Wed) 23:27
コンピュータ | Comment | trackback (0)

Unicodeだと使える文字

曲名に「✿」と入った曲があって、そんな文字使うんだと驚いた。

絵文字かなと思ったけど、U+273Fということで、Unicodeでは携帯電話由来の絵文字ではなく装飾記号(Dingbats)に登録されている。

周りを見てみると、丸囲みの数字なども含まれているが、絵文字のようなのも多い。


こんな字あったっけ? と思ったが、やはりJISコードには登録されていない文字だ。

JISの文字コードもいろいろあるが、基本的なのが JIS X 0208にある文字だ。

ここに登録されている文字は昔から無難に使えると言われていた。

JIS X 0208には登録されていないが、Shift_JIS というか CP932 だけで使える文字もあったりして複雑だったんだよね。

ただ、そういうのを含めても「✿」というのは登録されていない。


というわけで、従来では日本のコンピュータでは使えなかった文字ですね。

というか、今までどの文字コードにもなくて、Unicodeで新規で追加された文字のような気がするんだよな。

あと、Dingbatsに登録されている文字には絵文字と併用になっている文字もある。

例えば ☎ は絵文字併用の文字で、Androidで見ると絵文字として表示されるし、絵文字として入力することもできる。

ただ、✿ は絵文字として使われる文字ではないので、なかなか出しにくいよね。


曲名や歌手の名前で「♥」または「♡」が入ることがある。

ハートマークは一般的な記号だが、JIS X 0208 には登録されていないし、CP932 にもなかった。

そんな経緯もあって、ハートマークが収録されていないフォントもある。

EUC-JP, Shift_JIS, ISO-2022-JPといった文字エンコーディングで使えないので、

表記上は▼など他の文字に置き換えて、注釈で「『▼』は黒塗りハートマーク」などと記載することもあった。

もはや UTF-8 のようなUnicodeベースの文字エンコーディングが普及したので、あまり気にせず使われることも増えたが、

コピペすると正しく表記されないなどトラブルを引き起こしかねないのが悩み所である。


それにしても「✿」なんてのが入ってくるのは初めて見たな。

Unicodeで使える文字は増えたが、実際に日本で使うかというとそうとも言えない。

例えばドイツ語の「ß」とか、今は日本でもUnicodeなら使えるけど、そもそもほとんど使わない。

結局は大半は JIS X 0208 や CP392 の範囲で済まされているというのが実情ではないだろうか。

そんな中で特徴的なのがハートマークと絵文字かなぁと。使うところではかなり高頻度に使われる文字種だ。

特に絵文字はE-mailのUnicode化を推し進めるきっかけになったんじゃないかな。

以前はE-mailと言えばISO-2022-JP 一択だったが、最近では絵文字対応なども考慮してE-mailでUTF-8が使われることも増えた。

そもそもISO-2022-JPってどうなんだよと思ってたので、よい方向だと思いますけどね。


Author : hidemaro
Date : 2018/05/23(Wed) 22:23
コンピュータ | Comment | trackback (0)

RAMチェックって何のため?

組み込みシステムではしばしばRAMチェックを行うことがあるよう。

RAMの読み書きが正しく出来ているか確認するんだけど、なんでそんなことするんだ?


というわけでチームリーダーに聞いてみた。

すると、ワンチップマイコンだとそこまで必要性はないかもしれないが、と前置きした上で、

メモリが外付けされている場合、CPU~メモリ間のバスが故障していないかをチェックしたいと。

やり方はいろいろあるのだが、データを書いて、データが正しく読めるか確認する。

アドレス・データのパターンをうまくやると、データバス・アドレスバスの故障を検出することができるわけだ。

記憶素子の健全性を確認するという意味合いもあるのは確かだが、バスの健全性を確認する方が意味合いとしては大きいのでは? とのことだった。


データバスの故障を検出する方法は比較的簡単だ。、

あるアドレスに 0x55555555 と書いて 0x55555555 を読み出す、0xAAAAAAAA を書き込んで 0xAAAAAAAA を読み出すという方法がある。

もし、データバスの0bit目が故障して0固定になっていたら、0x55555555 を書き込んでも 0x55555554 としか読めない。

16bit目が1固定になっていたら 0xAAAAAAAA を書き込んでも 0xAAABAAAA と読めてしまう。

アドレスバスの故障検出はもうちょっと複雑だが、書き込んだアドレス以外のデータが壊されていないか確認するというのが基本的な考え。


RAMチェックもいろいろな方式があるけど、現在のRAMデータを破壊する方式が多い。

システムが動いているときにメモリの中身が壊されたら正しく動くわけはないわけで、

起動時にメモリを使い始める前にRAMチェックを行う必要がある。

稼働中にRAMチェックを行うシステムもあるみたいですけどね。

破壊してもよい領域でRAMチェックを行うか、データを破壊しない方式でRAMチェックを行う必要がある。

いずれにせよ、どういう故障を想定してRAMチェックするのかということは考えるべきですね。

それによってやり方も変わってくるので。バスの心配ならワンチップマイコンなら不要な気はするので。


PCのRAMチェックといえば memtest86 が有名だが、けっこういろいろな故障を想定しているんだね。

MemTest86 Technical Information #Individual Test Descriptions

アドレスバスの故障、データバスの故障、記憶素子の故障 というのもあるし、

キャッシュ回路やバッファ回路の故障をあぶり出せるように、アクセス順序を変えたり、データ幅を変えたりいろいろやっている。

どこまでチェックするかって話ではあるんだけど、それはまさにどういう故障を想定するかという話なんだよね。

そこを考えないと的確なRAMチェックにならないと理解した。


Author : hidemaro
Date : 2018/05/22(Tue) 23:41
コンピュータ | Comment | trackback (0)

アセンブラ時代の工夫?

最近、アセンブラでかかれた昔のプログラムを解読している。

最初はバイナリを解析させられるのかと思ったが、ちゃんとしたソースコードがあったから助かった。

あと設計を書いた資料もそれなりにあって、といっても細かい部分はソースコードを見ないとわからないんだけど。


アセンブラでプログラミングなんてあんまりやったことはないけど、高専時代にちょっとやった。

細かい記法はマイコンのコアによるけど、基本的なところは同じだ。

ニーモニックコードの意味とかはマイコンのマニュアルを見ないとわからないけど、

これがロード命令で、これが足し算でとかいうぐらいは見ればだいたいわかる。


アセンブラで書いているのは、まさにCPUの動作そのものなので、人間にとって理解しやすいかはなんとも言えない。

もともと人間が書いたソースコードなので、人間が理解できる範囲で記述されているのは確かなのだが。

とはいえ、レジスタの値を破壊しながら処理をしていくのは、なかなか読みにくい。

ビットシフトをすると、あふれたビットはキャリーフラグに入る。

これを利用して レジスタBを1ビット右シフト→キャリーフラグで分岐 ということをやるプログラムがけっこうあった。

Cだと普通はこんな書き方をするんじゃないかなぁってのが、

long flg=1, result=0;
for(long i=0;i<8;i++){
  if(((enable & flg) == flg) && judge[i]){
    result |= flg;
  }
  flg <<= 1;
}

こうなるような感じですかね。

for(long i=0;i<8;i++){
  if(((enable & 0x01) == 0x01) && judge[i]){
    result = (result>>1) | 0x80;
  }else{
    result = (result>>1);
  }
  enable >>= 1;
}

結果的に得られるものは一緒のはずだけど、どっちが直感的かっていうと前者だよね。


あと、リソースを節約するためかしらないけど、1つの変数のビットごとに意味を割り付けてあることが多いのも困った話だ。

変数Aの bit0に完了フラグ、bit5~2に動作モード、bit7~6に外部入力の状態とか。

こんなの無理やり1つの変数にまとめるなよって思うんだけどね。

ビット単位に割り付けたせいで、ビットシフト、AND・OR演算、ビット操作命令 を複雑に操る必要があるんだよね。

それをCで書いてあるならまだよいのだが、アセンブラですからね。


さすがにこれからアセンブラでコードを書くと言うことはないのでご安心を。

この解析結果を基に、新しいシステムの仕様を決めて、新しく作るのはCで書くことになる。

こうやってアセンブラのソースコードを読むと、わかりにくいなと思う一方で、人間の理解を超えない範囲で書かれていることに気付く。

Cで書いてコンパイラに機械語を作らせると、人間が理解できない機械語でもよいから、性能をもっとも引き出せる機械語を生成できる可能性が高い。

昔はマイコンのリソースも限られていたから、リソースの割り付けを人間がうまく工夫して高速化することもできたのだろう。

でもそんなのはきっと過去の話。今はコンパイラにお任せが最善策だろう。

Cで書かれていればアセンブラよりははるかに理解しやすいですから。それで十分かはさておき。


Author : hidemaro
Date : 2018/04/09(Mon) 22:42
コンピュータ | Comment | trackback (0)

プリレンダリングでなくてもスマホは燃えない

今どきのスマートフォン向けゲームはリッチなものが多いんだけど。

『アイドルマスター ミリオンライブ! シアターデイズ』の“13人ライブ”ってどんなもの? 田中琴葉の到着を記念したプチ特集も【先出し週刊ファミ通】

これは2月のニュースだが「アイドルマスター ミリオンライブ! シアターデイズ」に 13人ライブ という新モードが追加されるという話が出ている。

この話を聞いて「スマホ爆発しそう」とか性能面での不安を言う人もいたが、

この時点ではそうでもないのでは? という話もあった。


このゲームではコミュ画面、ライブ画面ともにリアルタイム3Dレンダリングでキャラクタを描いている。

それなりに性能面での要求はあって、といっても今どきのスマートフォンなら問題はないが。

でも電力消費は相当ですね。けっこう熱くなる。

従来、同時に描画するキャラクタはせいぜい5人ぐらいだから、

それが13人になると性能的には大変なのでは? という心配があったと。

でも、そこまで人数が多いのならば、あらかじめ作成した動画を再生するという プリレンダリング という手もあるのでは? という話もあった。

実際、過去にアイドルマスターシリーズではPS3で13人ライブがあったが、これはプリレンダリングだったそうだ。


ただし、プリレンダリングにするには条件があって、キャラクタの配置・衣装が固定できることだ。

好きなキャラクタを選んで、好きな順に並べて、持っている衣装から好きな衣装を選んで、とできるのはリアルタイムレンダリングだからこそ。

この13人ライブのコンセプトからして、並べられるキャラクタは13人固定でよい。並び順も固定というのなら、それはやむを得ないだろう。

でも、衣装は固定ってわけにはいかないんだよね。

なぜならば、この時点で公開されていた映像では「FairyTaleじゃいられない」の専用衣装を使っていたが、これは有料で販売予定となっている。

ということはこの衣装で固定にしてしまうと、衣装を購入した人以外は13人ライブは使えないことになる。

全員が持っている衣装「シャイニートリニティ」の映像と2種類用意しておけば、買わないとプレイできないということは避けられるが、他にもいろいろ衣装ありますからね。


そんな13人ライブの続報が先週に出た。

開発中のものを実際にプレイして見せてくれたのだが、なんとキャラクタの並び順は変えられるわ、衣装は変えられるわ。

すなわち、リアルタイムレンダリングだったのだ。

全員個別の衣装を選べるようで、理論上は全員をSSR固有衣装に交換することもできそうな感じだった。

これは予想外だったのだが、リアルタイムレンダリングならあえて制限する理由もないのは確か。

これを見て「スマホ爆発しそう」とか言う人が続出したのは相変わらずなのだが。


PS3でプリレンダリングでやったのに、スマートフォンでリアルタイムレンダリング? という話もあったが、

今どきのスマートフォンの性能はよいというのと、あと画面も小さいので妥協できるというのもあったのかなと言われている。

大画面で見る前提ではないってのは確かにありそうだなと思った。


決まり切っているものを描画するならプリレンダリングってのはよい方法ではあるんですよね。

その昔、ゲームボーイアドバンスの頃にプリレンダリングの3Dが取り入れられたゲームがあるという話があった。

ゲームボーイアドバンスは3Dを描画するエンジンを持っていない。けどあらかじめ作成した映像を表示するならやりようはあった。

そんなのあえて言うほどのこと? って感じはするけど、当時はまだまだドット絵が多かったってことなんでしょうね。

そんな中で、リアリティのある空間表現が取り入れられたというのは画期的だと言うことで話題になったんだろう。

さすがに3D描画機能自体を持たないからプリレンダリングってのは今はないだろうけど、今でも使い所はあると思いますよ。


Author : hidemaro
Date : 2018/04/07(Sat) 23:49
コンピュータ | Comment | trackback (0)

リモートデスクトップと画面転送

職場で来月に在宅勤務キャンペーンをやるそうだ。

在宅勤務なら午前だけ勤務もできる?

このときに書いたけど、このキャンペーンに合わせて新人の定義が変わり、僕も在宅勤務の対象者になるという話。

その結果として、僕もキャンペーン対象者になると。


さて、今月。在宅勤務でやることが想定される仕事として、論理シミュレーションがある。

うちの職場では論理シミュレーションをワークステーションで行うので、

リモートデスクトップを使ってワークステーションにアクセスして論理シミュレーションを行う。

これを在宅勤務でも出来るのかと思って、いろいろ調べていたらできることがわかった。

もともとリモートでやってるので、リモートでやりやすい仕事なのは確かで理にかなった話ではある。


ところで、在宅勤務で使うリモートアクセスの方式にはいくつかある。

リモートアクセスのどれを選ぶか

想定しているのはここでいうところの画面転送方式だ。

リモートデスクトップ+画面転送ということは、なんと画面転送→画面転送 ってなるんだよね。

なんてアホらしい。


でも意外にも性能は悪くない。事前調査の結果、わりと社内でいるのと同じように仕事が出来る。

画面転送ってオーバーヘッドが大きそうなのだけど、いろいろ効率化されているようで。

だから一見非効率だけど、意外といけるみたいで。


というわけで今の仕事なら在宅勤務は全く問題ないなと思っている。

ちょうどよかったなと。

ハードウェアが必要な仕事だとなかなか在宅勤務に向かないからね。


Author : hidemaro
Date : 2018/01/31(Wed) 22:59
コンピュータ | Comment | trackback (0)

Tools