レンズ(マニアックなハードウェアに向かいあわされている件)

カメラはレンズで光を集めて映像を得るデバイス。 レンズの性質によって、得られる映像は当然変わるもの。

しかし、その性質を決める特徴は様々あって、 好きでもなければなかなか頭に入ってはこない。

f値単焦点焦点距離被写界深度、etc.

一つのレンズであるから、仕組みについて納得すれば それぞれの意味がわかり効果がわかって選べるように、 多分なるのだろう。

ホワイトバランスや露光、色温度などの設定、 フォーカスや露出のオートとマニュアルなどなど。 良い映像を知っていて、目指すものが明確ならば コントロールに必要な指標として操作できるのだろう、おそらく。

しかしまぁ、カメラには興味がわかない。 光に興味ないかというと、朝日や夕陽、日暮れどきの山並みの 色が変化していく様は素敵なのだが。

これまでに一度だけ、写真を見て「写真の力」を感じたことがあった。 多摩美大の卒業制作展で、なんてことのない自然な田舎の風景だったのに 妙に惹きつけられる、パワーのある写真。

制作者がいたので話を聞いてみると、エフェクトなどの加工は一切なし、とのこと。 撮って現像しただけで、ぐいっと迫る力(そうか迫力か)が出る(込める?)とは、 摩訶不思議。

いずれにせよ、、先日のスピーチコンテストの録画で、一眼とビデオカメラの 映像にあまりにも差があったのは、かなわん事実。

次のイベントでは、カメラが少ないからリスクも小さいけれど、ちょっとは 機材をコントロールして状況に対処できるように、準備とリハーサルをしておこう。

サーバサイド プログラミング with PHP(ITを学ぶのに想像力が必要な件)

久しぶりに、PHPによるサーバサイドプログラミングの授業。

本当は、Javaサーブレットと書いてあるのだが、変更した。 そんな効率の悪いことはできん。

サーバサイドでもクライアントサイドでも、システムの「奥行き」を 感じていないと理解が全く進まない。

システムの構成を図に描くと、2次元の平面でとりあえず描く、 描けてしまうけれども、「webサイトを作ろう。サーバも動かして」 となると、話は別になる。

そもそもパソコンの画面で起きる現象を見ていると、その裏側の システム、その構造を把握するのは難しい。

HTMLでwebページに何か表示するのと、 JavaScriptでwebページに何か表示するのと、 PHPでwebページに何か表示するのと、 どう違うのか? どう選ぶのか?

HTMLで書くと、ページソースを見ても内容は確認できる。 JavaScriptで書くと、条件によって内容が変わったり、エラーによって表示されなくなったりする。 PHPで書くと、webブラウザ側では結果を受け取るだけだから、どう制御されているかは見えない。

何をしたいか、どうやりたいか、で決めれば良いのだが、 それを考えるには個々の性質を把握していないと、 どう違うかがわからない。従ってどう使い分けるかわからない。

つまり、単純に「こうもできる」「こんな方法もある」と言われても、 一つのことを実現するのに複数の手段があったら、困るだけ。

「操作と結果」だけしか頭にないと、決められない。 また、それぞれの関係がわからないので、「なぜ複数あるのか、学ぶのか」 意義がわからなくなる。

意義のわからない事に取り組んでいる/やらされていると思うと、 自己肯定感、自己効力感が落ちる。

徒労になり、とりあえず動けば同じ、という考え方に落ち着く。

そんなふうに考えている輩にインストラクションするのも 10倍くらい徒労感が溢れるので、やっておれん。

というわけで、サーバサイドプログラミングを学ぶ機会があるなら、 「サーバを起動」して、DocumentRootにコンテンツを置き、 codeを書いてダイナミックなwebページを作ってみるのが良い。

一つずつ概念に触れて、整理していく。 「client / server」のやりとりを脳内に描き、 「Not Found」はサーバが動いてないと見られない(サーバが動いているとわかる)ことを知り、 「入力フォーム」でユーザが入力したデータがどう受け渡されていくかを観察する。

メッセージ一つでもいいから、webブラウザで入力されてからDBに格納されるまでの 流れを把握できると、「仕組み」と「振舞い」がわかってくる。

もちろんそれは、Javaサーブレットでも、できないことはないのだが。 サーブレットエンジンが入ると、役者が増えすぎて理解が面倒になる。

「システム」や「関数」、「写像」などの概念を身につけていないと、 ただ単に「扱う単語や手間が増えただけ」になってしまい、効果が減。

そこで、XAMPPでいいから、自分の手で動かしてみよう、となる。 いずれにせよ「仕組み」と「連携」を想像して理解する能力は必要だが、 比較的扱いやすいので、エクササイズを順番に与えると、わかりやすくはなる。

もっとも、そもそも仕組みを把握しようとする心がないと、、 それは、どうしようもない。全ての取り組み、試みは崩れ落ちる。

だから、「話を聞いてない」「理解しようとしていない」とか、 そもそも「理解する/できた」経験がなく、正しい状態を知らない、 というのは悪である。

知らない/わからないものが、わかる/できるようになる事を 経験していないと、まぁ対応できない。

つまり、変わる事の意義、変わる方法を知らない・信じてないので 行動できない。従って永遠に変わらない。即ち学べない、学ぶ能力がないのである。

ITじゃなければ、、操作と結果だけでこなせる部分もかなりあるだろうけど、 画面で覗くしかないITは、想像力に支えられること大なので、まぁ厳しいな。

Flaskとファイル操作(または、2=1+1ではない件)

期末テスト代わりの演習課題として、Flaskでwebブラウザからの入出力と、 ファイル操作の組み合わせ。

入力フォームを使ってブラウザからデータを送信する練習。 基本的な入力として、5つ。

・テキスト( type="text" ) ・パスワード( type="password" ) ・ラジオボタン(変換するな、mac。。🔘)( type="radio" ) ・プルダウンメニュー ( select ) ・テキストエリア( textarea )

先週までに「テキスト」と「パスワード」しか扱っていなかったので、 他の3つを追加。

まず一つずつ、フォームを作成して、送信〜受信〜データを出力、の練習。

<form action="radio_app" method="POST">
 神奈川<input type="radio" name="address" value="kanagawa">
 東京<input type="radio" name="address" value="tokyo">
 <input type="submit" value="OK">
</form>

色々書くものはあるけれども、、とりあえず動作させることを優先 & 可能な限りコンパクトに。

from flask import Flask, render_template, request

app = Flask(__name__)

@app.route('/radio')
def radio():
    return render_template('radio.html')

@app.route('/radio_app')
def radio_app():
    address = request.form['address']
    return address

if __name__=="__main__":
    app.run(debug=True)

などと1個ずつ試しておいて、最後に「今日いちばん難しい問題」として、 「入力の全種類を使ってフォームを作成せよ。また、受信したデータをテキストファイルに書き込むこと」

テキストファイルへの書き込みも、前回やってあるので、 新しい要素はなし。調べる必要もなし。

しかし、、初心者にやらせるには「2=1+1」ではないことを知る必要がある。

要素技術が個別に揃っていても、それらを「組み合わせる」スキルが必要だからだ。

学生には、「アッポーとペンだけで、アッポーペンにはならない!」と体感できる問題になる。

具体的には、学生は単純に積み重ねようとするので、 1ページに「フォームが5個」ある状態になる。 (当然、submitボタンも5個ある!)

でもそれでは、5種類のデータを同時に送信できないので、 少し抽象化して整理できた者だけが、一歩進んで入力フォームを 扱えるようになる。

簡単なことだし、できてしまえば大したことでもない。 しかしながら、できない者には永遠にできない。

まず「こう書くと何ができるか、どんな仕組みなのか」が、掴めるか否か。

次に「組み合わせるとどうなるか、どう扱えば”合体”させられるのか」が壁となる。 1種類ずつのフォームの「形」ではなく「仕組み・ルール」を把握して使えるか、ということ。

まじめに丁寧に「書き写す」だけじゃダメだと、役にたたんと知るかどうか。 技術を学ぶ上で、そこが一番の「壁」。

プログラミングを基礎で言うと「繰り返し処理の中に条件分岐を入れる」ようなもの。 「if文」を習って、「for文」が書けた後、その2つを組み合わせて使えるかどうか。

毎年プログラミングの授業では、「helloと繰り返し30回出力。ただし5回に1回 ALOHA! と出力させろ」 を出題する。

まぁこれが、全然できない。 それはわかっているのだが、要素技術を知っても「組み合わせ」のスキルはまた別に要る、 ということを教えるには少し教師にもスキルが求められる。

もちろん学生にも、きちんと取り組む態度が要求される。 自分で考えることができないと、「知っているのにまだ何かが足りない(から、できない)」 という状況にならないから。

「正解を見せてもらって実行するだけ」とか「ググって見つけて、とにかく動けばOK(意味わからなくてよい)」 などと思っている、あるいは、メタ認知のかけらもなく「そういう態度で生きていくことしかしていない」者は、 そもそも気づくチャンスがないので、変われないし変わらない。

「学ぶことは変わること」なので、変わる能力がない者は永遠に変わらない。 そういう人間を作っちゃダメなんだが、、世の中の大人は、18歳までにそういうダメな躾を してしまうんだよなぁ。ホント勘弁して。

動画の収録と編集は「計画的」に!

先日のスピーチコンテスト動画、とりあえず版を公開しておいて、 ディレクターズカットにかかろう、と思っていたら、やばかった件。

Final Cut Proにも慣れておかねばならんので、クラス毎に1本ずつ まとめてみようという取り組み。

いや本当に、やばすぎる。 これをやってたら地獄を見る。

配信クルーはかなりの対応力を発揮してイベントを回してくれており、 本当に感心&感謝するところ。

しかしイベント全体の段取りが悪く、演者のリハーサルは一切なし。 すなわち、ほぼ「切り替えを待たずに喋り始める」という惨劇。

エコーを避けるため、ミキサー側ではいちいちマイクをON /OFFしていたので、 合わせ技で音声はえらい事になっており、揃えるのが大変。

単純にゲインを上げても、遠いマイクに入った音なので、ノイズが拡大されてかなり不自然。 それがまた、セリフの途中まで/途中からなので、どないするもんか見当もつかない、、

トーシロが背伸びどころか走り高跳びしても届かない感じ。 何ができるか、何からやるのが適しているか、判断するスキルがない状態で 無理矢理やってみるのは、なかなかキツい。

コーチがいるなら、素直に反応してアドバイスから吸収すれば良いが、 いないので、、徒手空拳で殴りかかる感じで結構しんどい。

知識、経験、スキルがあると楽になるもんだと、体感的想像ができて、 面白いといえば面白いけれど。

まーなんとかクリンチとロープに逃げながら、しのぐしかない。 笑えるくらいやばいので、割り切りやすいのが好都合である。

とりあえず。

AIで顔認証をやらざるを得ない状況に陥るとは、、

9月から毎月1回、「先端技術研究会」という取り組み(オンライン)に参加している。

KIA(神奈川県情報サービス産業協会)が毎年実施しているもので、テーマはいろいろ。 初参加にあたり、AI系のテーマ「顔認証技術」を選択したところ、商用の顔認証システム 「SAFR」のアカウントを使わせてもらえることになった。

www.ntt.com

しかしこの2ヶ月、ITコンテスト、学内スピーチコンテストのライブ配信と動画編集、 卒業制作とバタバタしまくり、全然試す余裕なし。

せっかくの機会に残念なことだと思っていたら、卒業制作のテーマに「AI顔認証」が登場。 出席管理を実装するという。

学校らしい、かわいらしい思いつき、、ではあるが、実際取り組むとなると、 ただ顔が判るだけではものたりない。

出席の確認だけなら、座席が固定されているのだから、顔認証しなくてもできる。 AIを使わず、画像処理だけで十分できそうだ。

わざわざ顔を見るのだから、「今朝の調子はどうか」とか、「機嫌が良さそう/悪そう」 「疲れている様子」などの特徴も取得したい。

実用を考えるなら、ビジネス目線で捉えてみるなら、競争力が必要だ。

、、というわけで、「正面でなく横顔で認証できる」とか「状態を把握する」機能に 挑戦してみないとだめかな。

しかしその機能は、、SAFRそのもの。 顔認証と性別や感情の読み取りを合わせて1秒以下で行うSAFRと勝負できる見込みは ないけれど、背中を追いかけて行くことで理解が深まるはず。

試せてなくて残念、、とは思っていたけれど、なんでここで顔認証くるかなぁ。 しょうがないので研究会でその旨を白状し、取り組みの様子を共有することにした。

職業エンジニアは、SAFRを手作りする余裕はないだろうから、少しは貢献できると 割り切ることにする。

要するに勉強だ。あと11.5週。

YouTube動画を高画質でダウンロード

ライブ配信アーカイブを編集したい場合、配信側でアーカイブしていなければダウンロードする。 しかし普通にダウンロードすると 720p になってしまい、1080pで配信したのに、かなり残念。

とりあえず応急処置(あまりにもマズい部分だけ修正)版で公開するため編集したが、 その直後にアプリを発見。(正確にはnote記事を発見)

AWSジャパンの人が「無料だが特におかしな現象は起きなかった」として紹介。 webサイトにアクセスしてみると、winだけでなく mac も対応。

note.com

こりゃあ便利なので、1年で怪しい現象なし、となれば使う。 (ほんとに、信頼できる情報は貴重)

応急処置に続いて、登壇者一人ずつの動画を作り、映像音声を修正したイベント動画を 作る予定だったので、今度はフルHDで編集。

まぁそうは言っても、カメラによる明るさの違いが出過ぎていて、 明るさと色のコントロールだけでも倒れそうだけど。

帰宅して話してみると「今頃何言ってんの。レンズの明るさが足りないんでしょ」 とのこと。

カメラの設定でなんとか、、ならないのね。 編集の際にカラーグレーディング、または明るさと色味の修正を 試すしかないが、撮る時点で明るさをコントロールしないとダメなわけか。

f値が〜、なんて話は他人事だと思ってたけど、光をちゃんと扱わないと、 映像が撮れない。やっぱりレンズの勉強しないとだめらしい。

どうしてこうも「今まで避けてきた方向」に進まされるんだろうか。 この10年そればっかり。

学生時代の同期や先輩が見たら、呆れるだろうなぁ。 ま、仕方ない。

動画を修正、とりあえず版

イベントのYouTube LIVE配信、アーカイブが残ることまで 考えが及ばずいろいろ手直しの時間が必要。

昼休みやイベント前後の映像をカットして 修正の必要な部分に応急処置。

最もまずいのは国旗が上下反転していたこと。 ライブ中に学生スタッフが直してくれたものの ひとつ残っていた。

それも1分くらいで修正されたのだが その場で腕を上げていく対応力に関心。

しかしアーカイブは残るので、反転した部分に 正しい画像を重ねて書き出し。

他にもマイク位置を直した際のノイズをカットしたり スライドを直したり。とりあえず最低限、と思うものの いくつかあって最後の書き出しをスタートして帰宅。

いやほんとにイベントのライブ配信は、段取り命。 無駄が鬼のように増えていく。

ライブ配信ディレクションシートを書き上げずに 配信してはならんと再認識。

webdirection.jp

今月のイベントは万全でいこう。