mieki256's diary



2013/03/26(火) [n年前の日記]

#1 [digital] 超解像技術について少し調べてる

複数の画像から高解像度の画像を生成する技術があったはず、と思って検索。もしかすると、「超解像」と呼ばれるソレかもしれないけど。自分が今使えるデジカメは、どれも解像度が低いので、連写した画像から高解像度の画像を作れるなら、試してみたいなと。

_ImageD2 というフリーソフトに遭遇。試してみたところ、ン時間単位で処理時間がかかったにも関わらず、さっぱり高解像度画像には見えなくて。なんでだろうと思って調べ直したところ、自分はこの手の「超解像技術」について、ずっと勘違いをしていたことに気付いたり。

複数の画像から、高解像度画像を作る際には、えてして動画を使うらしい。というのも、カメラが微妙に動いていることを期待して、なのだとか。現在見ているフレームだけでは、拡大に必要な情報が足りてなかったとしても、前後のフレームなら、カメラが微妙に動いていることで、拡大に使える画素情報が含まれてる状態かもしれん ―― と考えて、前後のフレームから画素情報を、探して、拾って、現在のフレームに埋めていく、てのがその手の処理だそうで。

自分が実験に使った複数画像は、カメラを三脚でガッチリ固定して撮影したモノなので、カメラが全然動いてない。同じ場所を連写撮影しただけだから、拡大後にドットが足りてない場所を埋めるための画素情報がどの画像にも含まれてない。道理で、全く高解像度になっていかないわけで。

なら、手持ち撮影で連写した画像なら上手くいくのでは…。試しに、手持ち撮影画像を ImageD2 に処理させたら、エラーが発生して強制終了。どうやら、各画像の移動量が大き過ぎると落ちるらしい…。

何にせよ、色々と勉強になった。とりあえず調べた範囲で分かったことをメモ。超解像技術は、今のところ大別すると2つあるそうで。 前者は、「他の画像なら拡大に使える情報が含まれてるかも」と期待しながら処理をする方法だけど。後者の、1つの画像から高解像度画像を生成する方法も、ざっと眺めたところ2種類あるように見えた。 辞書方式は、かなり高解像度の画像が出てくるようで、サンプル紹介を見ていてビックリしたのだけど。原理からして、本当に元々そういう画像だったのか、大変疑問が残ってしまう方法なわけで。ただ、人の顔を復元するとか、ナンバープレートを復元するとか、ジャンルを限定してしまえば ―― 元々あり得たはずの高解像度パターンが結構限定されている状態なら、かなりイイ感じに推測できるっぽい。

辞書方式云々。 :

#2 [pc] プラグインメニューが長くなってきてちょっと困ってる

GIMPのプラグインメニューがちょっと長くなってきていて。どうしたもんか、どうにかならんかと。
GIMP menu

ついでに言えば、Audacityのプラグインメニューも長過ぎて困ってたり。
Audacity menu

さらについでに言えば、Metasequoiaのメニューも長過ぎて。
Metasequoia menu 1
Metasequoia menu 2
まあ、Metasequoia は、 _Custom Menu というプラグインを使うとこのへん劇的に改善するのでアレなんですけど。本当に、このプラグインはありがたい…。

FL Studio も…。いや、これはまだ、横に広げてくれるだけマシですけど。
FL Studio menu

とにかく、その手のアレは、メニューを選択した瞬間、こんな気分に。
うわ…
*1

「ちょ、おま、プラグイン入れ過ぎwww」とか笑われそう。いやいや、でもさ、「これは便利そう!」→「いつか使うかもしれない!」→「とりあえずインストール!」てのがプラグインってものじゃないですか? だから仕方ないよね? ね? *2

しかしこのあたり、ユーザの性癖を笑って馬鹿にして済ませられる程度の話ではないよなー、と思っていたりもするのです。要するにコレって、GUIにずっとまとわりついている問題なわけですよ。

GUIにまとわりついてる問題。 :

  • Microsoft Office 2007 がリボンUIを導入したのはなぜか?
  • Windows Vista/7 がスタートメニューの大改編を行ったのはなぜか?
  • Ubuntu Linux が Unity Dash を盛り込んだのはなぜか?
さて、なぜでしょうか、と。

「GUIを用いた製品は、高機能化に伴って、メニュー項目数が膨大になってしまう」
「メニュー項目数が増えると、目的の項目を探し出すことすら困難になる」

そういう問題が、GUIにはずっと存在しているわけですよ。そして、各OS・各アプリは、その問題をどうやって解決するか悩みに悩んで、それぞれがこういう解答を出してきた、というのが現状なわけで。

前述の、プラグインメニューのスクリーンショットもソレで。プラグイン追加で、機能はどんどん増えていく。増えていくけど、呼び出すことが困難になっていく。その実例の一つ、と言えるわけです。

実は、今から15年以上も前、Windows 95/98の時代ですら、一応そのあたりについて解答は盛り込まれていました。
  • スタートメニュー内の項目の並び方を、ユーザが好きなように変更できた。
  • スタートメニューが入っているフォルダの中にサブフォルダを作ってショートカットファイルを移動すれば、ユーザが好きなようにメニューを階層化できた。
つまり、メニューにおける「並び」と「階層」、この2つをカスタマイズすることができたわけですが。個人的には、この2つをユーザがカスタマイズできるだけでも結構違うだろうと思っているのですけど。
  • 並びを変えられたら、自分がよく使いそうな項目だけを、選びやすい場所に持ってくることができる。
  • 階層化ができれば、一度に表示される項目数を絞れる。画面全体にメニューが表示されて「うへえ」と思わずに済む。

しかし、前述の、GIMP、Audacity、Metasequoia、FL Studio などのアプリは、それすらできないわけで。
  • 各プラグインが、自分がどの階層に配置されるべきかの情報を持ってしまっている。ユーザがその情報を任意に変更できず、階層をカスタマイズできない。
  • メニュー項目の並びが、アプリ本体が持つ特定のルールに支配されていて、変更できない・固定されている。
今更、プラグインの仕様をUIを快適にするために変更します、なんてことはできませんし。プラグインは、そのアプリにとっての貴重な資産ですから、ソレを一旦捨てるなんてことはできない。なので、改善しようにも、これはなかなか厳しい。…言い方は悪いですが、それらアプリのGUIに対する取り組み・思想は、Windows 95が発売された1995年のレベルにも未だ至っていない、とすら言えてしまうのかもしれないなあ、とチラリと思ったりもします。

もっとも、各アプリは、メニュー表示をライブラリに任せてるだけなのでは、という気もするわけで…。もし、それぞれが使っているライブラリが、メニュー表示の処理に関して、何か改善を盛り込めば、それだけでずいぶん印象が違ってくるかもと想像していますが。例えば…。
  • 縦方向にだけ項目を並べず、FL Studio のように(あるいは昔のWindowsのように)横方向も活用するとか。せっかく16:9の横長ディスプレイが普及してるのに、ドット数が少ない縦方向ばかり使うのは理に適ってないですし。
  • 画面内に項目が収まらない時は、スクロールバーを出してしまうとか。何がツライかと言えば、最上部 or 最下部の三角マークを押し続け、目的の項目がスクロールで出現してくれるのをじっと待ってるのがツラいわけで。スクロールバーで「大体このへんにあったはず」と一気にスクロールできたら、能動的に操作してる感が得られて、全然違うだろうなと。
もちろん、アプリ本体でもできそうなこともありそうですが…。
  • pluginsフォルダ内に、特定の命名規則でフォルダを作り、そこにプラグインを入れたときだけ、フォルダ名に従った階層表示にするとか。例えば、「!生成」「!変換」等、頭に「!」をつけたフォルダ名にすると、そこだけ階層として扱いますよ、等々。
もっとも、そんな修正してる暇があったら、画像編集、波形編集、3DCGモデル制作等、目的とする作業に関する内部処理を改善したい、機能を追加したい、とフツーは思うでしょうし。

まあ、このへん色々と難しいですよね、ってことで。あの Microsoft ですら、毎回悩んで、違う解答出してきますし…。

とりあえず、そういう問題がGUIにはあるよねえ、てなだけの話でした。まあ、GUIに限らず日常生活の中にも似た問題がゴロゴロしてそうですけど。…なんとなく、「その手があったか!」てな解答がどこかにありそうな気もするんですが。

ジョブズは、パロアルト研究所でAltoとGUIを見て、ビビッときてLisaやMacを出したらしいけど。その当時、メニュー項目数が膨大になったらコレどうしようか、みたいなことを考えてた人は居るんだろうか。実はその当時の研究内容の中に、改善するための種があったりしないのかなあ。

Windows Vista/7のスタートメニューやUbuntuのDashとかそのへん。 :

余談。昨今のWindowsのスタートメニューや、UbuntuのDashを使ってると、これってGUIからCUIに戻ってるよなと思ったりするわけで。メニュー選択型のADVから、コマンド入力型のADVに逆戻りしてる印象が。

コマンド入力型は、以下の条件を満たしてる時は便利で速いわけですけど。
  • メニュー項目数が膨大で画面に収まらない。
  • 項目名をユーザがある程度覚えている。頭の中に、使いたい機能名・アプリ名が既に浮かんでる。
逆に、上記の条件を満たしてない時は、メニュー選択型のほうが便利で速いのですが。
  • メニュー項目数が少ない時は、マウスなりカーソルキー(十字ボタン)なりで選んだほうが速い。
  • 項目名をユーザが忘れてしまっていたら、コマンド入力型は手も足も出なくなる。
Emacs系のエディタとかそうですよね。「こういう機能があったはず。でも、なんてコマンド名(関数名)だったっけ…?」てな状態に自分はたまになるんですけど、こうなるとかえって時間がかかってしまう。

つまり昨今のWindowsやUbuntuは、大昔、皆がCUIでバシバシと操作してたあの感覚を、一般ユーザにも強要しようとしてる、とも言えそうな、そんな気もしていたりするわけで。…まあ、補完機能が強力なら、どうにかなるのかもしれないですけど。

いや、Ubuntu はともかく、Windowsは違うか。Windows8 のデスクトップは、またGUIに揺り戻しをしているような気もしてきた。指でポンポン選ぶだけで使えますよ、と嘯いて(?)ますもんね…。メニュー選択型へ戻ってるよな…。

おそらく、初心者に優しいのは、メニュー選択型ですよね。ファミコンのADVやRPGがコマンド入力型だったら、あんなにヒットしなかったと思うのですが。…本当にそうかなあ? どうなんだろう。

*1: _PAKUTASO - WEB制作向け無料写真素材 の写真を使わせていただきました。この写真、実に使えますねえ…。
*2: まあ、単に自分のコレクター属性が云々、てな話でしかないのかも、とも思うのだけど。

以上、1 日分です。

過去ログ表示

Prev - 2013/03 - Next
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project