Coded Chords - CLI

ハッカー風ターミナルでブルーウォーカー気分を

2026-11-03T08:53:54+09:00

Table of Contents

ドラマ『VIVANT』シーズン2は最終回を残すのみとなり、個人的に盛り上がっております。中でも凄腕ハッカーのBlue@walkerは、エンジニア界隈でも人気のようです。

そこで、ハッカー風ターミナルを表示する設定を自分でも作ってみました。

意外にちゃんと作られているBlue@walkerのターミナル

シーンによっては、Blue@walkerが$ssh bluewalker[Enter]と打っただけで「ハッキングできました」と言うなど、噴飯ものの表現もあり、ネタにされていました。しかし、Blue@walkerが使う画面をよく見ると、意外にしっかり作り込まれています。

画面は、開発ツールのAndroid Studioと、おそらく独自に作った表示を合成したもので、独自の表示にはARP偽装やBGP乗っ取りのスクリプトらしきものが流れています。Pythonのコードには、劇中の進行に合わせたかのようなコメントまで書かれています。エディタには、暗号化メッセージツールSignalのコードだったり、既知の脆弱性に関連すると思われるコードだったりが開かれており、なにか良からぬ取り組みを思わせます。プロセスの表示にはbashtopが使われています。

IPアドレスにはプライベートアドレスを使い、MACアドレスも明らかに連番と分かるダミーにするなど、プライバシーへの配慮もうかがえます。SSHの場面は笑ってしまいましたが、画面そのものはそれなりに作られています。

設計方針

偽のビルドログやダウンロード進捗を延々と流すgenactや、映画『マトリックス』風の画面を表示するcmatrixといったツールを使えば、それらしいターミナル画面は作れます。しかし今回は、自分にとって意味のある情報を表示したいと考え、次の方針を立てました。

意味のない表示はしない
画面分割はWezTermの機能で行う
ウィンドウは2つ使う
シェルコマンド1つで起動できる
管理者権限は使わない

ウィンドウを2つに分けたのは、画面いっぱいに表示しつつ、後からレイアウトを変えられる余地を残すためです。画面構成は次のとおりです。

  ウィンドウ 1（監視）                      ウィンドウ 2（株価・ニュース）
  ┌──────────────────┬──────────────────┐   ┌──────────────────┬──────────────────┐
  │ btm              │ gping            │   │ tickrs (summary) │ sysnews          │
  │                  ├──────────────────┤   │                  │                  │
  ├──────────────────┤ wtfutil          │   │                  │                  │
  │ macmon           │                  │   │                  │                  │
  └──────────────────┴──────────────────┘   └──────────────────┴──────────────────┘

ウィンドウ1の説明

ウィンドウ1は主にシステム関連情報を表示します。

btm

btmは、Rustで書かれたターミナル向けのシステムモニターです（プロジェクト名はbottom）。topやhtopと同じ系統のツールで、使用量の推移をグラフで表示できます。

CPU・メモリ（キャッシュメモリを含む）・温度・プロセス・ディスク・ネットワーク帯域を1つの画面にまとめて表示するので、資源の使用量と、それを使っているプロセスを見比べられます。Mac全体の負荷を一目でつかめる、ウィンドウ1の中心となる表示です。

btm の表示

macmon

macmonは、Apple Silicon搭載のMac向けのモニターツールで、消費電力・温度・GPUの状態を表示します。btmが見せるのはOSから見た資源の使用量で、macmonが見せるのはチップそのものの状態です。

同じ情報はmacOS標準のpowermetricsでも取れますが、こちらは管理者権限が必要です。macmonはsudoなしで動くため、常に表示しておけます。btmと見比べれば、CPUの負荷が電力や温度にどう表れているかを確かめられます。

macmon の表示

gping

gpingは、pingの応答時間をグラフで表示するツールです。複数の宛先に同時にpingを打ち、結果を1つのグラフに重ねて描けます。

宛先は、自宅のルーター（デフォルトゲートウェイ）と、Cloudflareの公開DNSサーバーである1.1.1.1の2か所です。通信が遅い、あるいは途切れたと感じたときは、2つの応答を比べれば原因のある場所を見分けられます。ルーターへの応答も乱れていれば原因は自宅内（ルーターやLAN）に、ルーターへの応答は安定していて1.1.1.1だけが乱れていれば自宅の外にあります。直近10分間の推移がグラフに残るので、少し前に起きた遅延や途切れにも後から気づけます。

wtfutil

wtfutil（WTF）は、ターミナル上にダッシュボードを作るツールです。天気・時計・Hacker Newsなどのモジュールが用意されていて、表示したいものを選んで1つの画面に並べられます。

ここには、システム監視以外で日頃確かめたい情報を集めました。東京の天気に加えて、東京・ニューヨーク・ロンドン・ロサンゼルスの現在時刻を表示しています。ウィンドウ2では米国株の値動きや海外のニュースを見るので、現地がいま何時かが分かれば、市場が開いている時間かどうかや、ニュースがいつ出たものかの見当がつきます。

グローバルIPアドレスと回線事業者も表示しています。VPNを経由しているか、どの回線から接続しているかがすぐ分かるので、gpingで通信の乱れに気づいたときの手がかりにもなります。バッテリーの残量と残り時間は、macmonの消費電力と合わせて見ると、負荷がバッテリーの減り方にどう響くかが分かります。Hacker Newsの見出しは、ウィンドウ2の時事ニュースでは拾いきれない技術系の話題を補います。

ウィンドウ2の説明

ウィンドウ2は株価とニュースを表示します。ウィンドウ1がこのMacと回線の状態を見せるのに対し、こちらは世の中の動きを見せます。

tickrs

tickrsは、ターミナルで株価のチャートを表示するツールで、データはYahoo! Financeから取得します。Apple・Amazon・IBM・Palantir・Tesla・Alphabetの6銘柄の値動きを、1銘柄数行の要約表示で並べています。銘柄はあくまでサンプルで、エンジニアが興味を持ちそうなものを適当に選びました。

ブラウザや証券会社のアプリを開かなくても、注目している銘柄の動きを目の端で追えます。ハッカー風の画面に流れる数字が架空のものではなく実際の相場であることも、意味のない表示はしないという今回の方針に合っています。

sysnews

sysnewsは自作のスクリプトで、BBCとNYT、ついでにNHKとYahoo!ニュースの新着の見出しを、時刻順に流し続けます。日本のメディアの偏向具合が酷いので、海外の報道もあわせてウォッチしておきたいと考えました。国内と海外のメディアを並べておけば、同じ時間帯に国内外で何が起きているかを一覧できます。

英語の見出しの翻訳と、私の関心事に合う見出しの強調にはClaude Codeを使っています。APIではなく、サブスクリプションで利用しているClaude Codeを呼び出す形にしています。モデルは軽量のHaikuを指定しています。

これで、海外のニュースも日本語で追えます。関心事に合う見出しは★付きの黄色で強調されるので、流れてくる見出しの中から自分に関係のあるものを見落としにくくなります。

見出しをクリックするとブラウザで記事が開き、あとから履歴を選んで開いたり、org-roamに保存したりもできます。見出しを眺めるだけで終わらず、気になった記事へすぐたどり着けます。

コード解説

今回の設定とスクリプト（sysmon・sysmon.yml・sysnews・tenki）は、すべてGistで公開しています。ここでは要点だけを抜き出して解説します。

WezTermの制御

ウィンドウとペインの組み立てには、WezTermに付属する wezterm cli を使っています。起動中のWezTermを外から操作するコマンドで、シェルスクリプトから新しいウィンドウを開いたり、ペインを分割したりできます。起動スクリプトsysmonのうち、2つのウィンドウを組み立てる部分は次のとおりです。

# ウィンドウ 1: 監視（左 btm / macmon、右 gping / wtfutil）
P=$(wezterm cli spawn --new-window -- \
  gping -n "$PING_INTERVAL" -b "$PING_WINDOW" "${ping_targets[@]}")
B=$(wezterm cli split-pane --pane-id "$P" --left --percent 50 -- \
  btm --enable_gpu --theme nord --enable_cache_memory)
wezterm cli split-pane --pane-id "$B" --bottom --percent 45 -- macmon >/dev/null
wezterm cli split-pane --pane-id "$P" --bottom --percent "$WTF_PERCENT" -- \
  wtfutil --config="$WTF_CONFIG" >/dev/null

# ウィンドウ 2: 株価（左。右上のヘルプ表示は隠す）とニュース（右）
T=$(wezterm cli spawn --new-window -- \
  tickrs --summary -s "$WATCHLIST" -i "$STOCK_INTERVAL" --hide-help)
wezterm cli split-pane --pane-id "$T" --right --percent 50 -- \
  sysnews -i "$NEWS_INTERVAL" >/dev/null

wezterm cli spawn --new-window は、新しいウィンドウを開いて指定したコマンドを起動し、そのペインのIDを出力します。wezterm cli split-pane は、--pane-id で指定したペインを --left や --bottom の方向に分割し、新しいペインの大きさを --percent の割合で決めます。分割したペインをさらに分割するときのために、返ってきたIDを変数に受け取っておきます。ウィンドウ1では、gpingのペイン（P）を左に分割してbtmを置き、btmのペイン（B）を下に分割してmacmonを、gpingのペインを下に分割してwtfutilを置いています。この先使わないIDは /dev/null に捨てています。

ただし、wezterm cli ではウィンドウの位置や大きさを指定できません。2つのウィンドウを画面のどこに置くかは、起動したあとに手で調整しています。

Claude Codeの呼び出し

sysnewsの要は、Claude Codeの claude -p（非対話モード）を、翻訳と判定を受け持つ部品として呼び出しているところです。新しく取得した見出しをまとめてJSONで渡し、見出しごとに日本語訳と、関心事に当たるかどうかの判定を返してもらいます。

cmd = [
    "claude", "-p",
    "--setting-sources", "",
    "--tools", "",
    "--no-session-persistence",
    "--model", CLAUDE_MODEL,
    "--output-format", "json",
    "--json-schema", json.dumps(SCHEMA),
    "--system-prompt", system_prompt(interests),
    "--", json.dumps(payload, ensure_ascii=False),
]

ポイントは、--json-schema で出力の形を決めていることです。見出しごとに、日本語の見出し（ja）、概要の訳（desc_ja）、関心事に当たるか（hit）、当たる理由（why）を返すようスキーマで指定しているので、返ってきた結果をそのままプログラムで扱えます。翻訳と判定を1回の呼び出しで済ませ、見出しもまとめて渡すので、呼び出しの回数も抑えられます。また、--tools "" と --setting-sources "" でツールも手元の設定も使わず、--no-session-persistence で会話の履歴も残しません。毎回まっさらな状態で、決まった仕事だけをさせる使い方です。

関心事は interests.md に自由な文章で書いておき、その内容をシステムプロンプトに埋め込んでいます。

if interests:
    p += (
        "- hit: 見出しと概要が、下の「注目する内容」のどれかに当てはまれば true。"
        "はっきり関係するものだけを true にし、迷うものは false にする。\n"
        "- why: hit が true のとき、どの項目に当たるかを 15 字以内の日本語で。"
        "false なら空文字。\n\n"
        f"注目する内容:\n{interests}\n"
    )

キーワードの一致で拾うのではなく、見出しと概要の意味からLLMが判断するので、関心事に書いた言葉が見出しに含まれていなくても、関係する記事を拾えます。一方で、何でも強調されてしまっては意味がありません。「迷うものはfalseにする」と指示して、はっきり関係するものだけに絞っています。

見出しをクリックするとブラウザが開くのは、OSC 8というエスケープシーケンスを使っているためです。OSC 8は、ターミナルへ表示する文字列にリンク先のURLを埋め込む仕組みです。WezTermなど対応しているターミナルでは、表示した文字列がそのままクリックできるリンクになります。

def link(url: str, text: str) -> str:
    """OSC 8 ハイパーリンク"""
    return f"\033]8;;{url}\033\\{text}\033]8;;\033\\"

表示した見出しは履歴としてファイルに残しておき、p キーでfzfの選択画面を開けるようにしています。プレビュー欄で概要（英語の記事は訳と原文）を確かめてから、Enterを押すとブラウザで開き、Ctrl-Bを押すとEmacsのノート管理パッケージorg-roamに保存できます。保存すると記事1件につき1つのノードを作り、記事のURLと概要を書き込みます。同じURLのノードがすでにあれば、重ねては作りません。流れていった見出しにも、あとから戻れます。

Claude Codeの呼び出しに失敗したときは、翻訳と強調をせず、元の見出しのまま表示を続けます。

まとめ

見た目のそれらしさだけなら、genactやcmatrixで十分です。今回は「意味のない表示はしない」を方針に、既存のターミナルツールと自作のスクリプトを組み合わせて、ハッカー風の画面を作りました。

ウィンドウ1ではこのMacと回線の状態を、ウィンドウ2では株価とニュースという世の中の動きを表示します。どのツールも管理者権限なしで動き、wezterm cli で組み立てているので、シェルコマンド1つで2つのウィンドウがそろいます。sysnewsではClaude Codeを翻訳と判定の部品として使い、海外のニュースを日本語で追いながら、関心のある見出しを見落とさないようにしました。

画面に流れているのは、作り物のログではなく、実際の数値と見出しです。設定とスクリプトはGistで公開しているので、表示するツールを差し替えて、自分にとって意味のある画面に組み替えてみてください。

gyrotriage — DJIドローン映像のブレを診断し、Gyroflowのパラメータを自動推定するツール

2026-03-07T22:00:00+09:00

Table of Contents

（2026-06-04更新） 本記事は当初、Gyroflowスタンドアロンアプリ向けの5つのパラメータを推奨する内容でした。その後、実運用のワークフローがDaVinci Resolve上のGyroflow OpenFXプラグインで完結することを踏まえ、推奨対象をプラグイン版「Adjust parameters」に一本化しました。以下では旧スタンドアロンアプリ版の記述に取り消し線を引き、新しい内容を併記しています。

Gyroflowのパラメータ調整は面倒である

DJI NeoやAvataシリーズでFPV撮影をしている方なら、Gyroflowでの後処理は日常的な作業だと思います。EISをオフにして撮影し、Gyroflowでスタビライズする。この流れ自体は確立されていますが、問題はGyroflowのパラメータ調整です。

~~Gyroflowには主に5つの調整パラメータがあります。~~

DaVinci ResolveなどでGyroflow OpenFXプラグインを使う場合、調整の中心になるのは「Adjust parameters」パネルのSmoothnessとZoom limitです。スタンドアロンアプリ版にあった細かなパラメータはプラグインのUIには現れず、.gyroflow プロジェクト側に焼き込まれます（2026-06-04更新）。

パラメータ	意味
Smoothness (1〜300)	スムージングの強度。高いほどブレを強く除去するが、意図した動きも鈍る
~~Max smoothness (s)~~	~~突発的なブレに対する最大補正量~~（プラグイン版では非対応）
~~Max smoothness at high velocity (s)~~	~~高速旋回時の補正上限。短くすると旋回への追従性が上がる~~（プラグイン版では非対応）
Zoom limit (%)	安定化で生じる黒縁を隠すためのズーム上限
~~Zooming speed (s)~~	~~Dynamic zoomingのFOV遷移速度~~（プラグイン版では非対応）
FOV	画角。算出対象外でベースライン1.0を提示

プラグインのSmoothnessは1〜300のスケール（デフォルト50）で、gyrotriageが従来出力していた百分率の値をそのまま入力できます。強く設定すればブレは消えますが、意図したカメラワークまで平滑化されたり、クロップで解像度が落ちたりします。適切な値はクリップごとに異なるため、毎回プレビューを見ながら試行錯誤することになります。

1本2本ならまだしも、フライト後に何十本ものクリップを処理するときは正直つらい作業です。

gyrotriageでパラメータ推定を自動化する

そこで作ったのが gyrotriage です。DJIドローンのMP4ファイルを渡すだけで、埋め込まれたモーションデータを解析し、ブレの度合いをスコアリングしつつ、~~Gyroflowの5つのパラメータ~~Gyroflow OpenFXプラグイン（DaVinci Resolve等）に入力するパラメータを自動で推定します。

考え方はシンプルです。パイロットが意図したカメラワーク（パン・チルト・旋回）と除去したいブレ（風や機体振動）では、動きの周波数帯域が異なります。ゆっくりしたパンは1Hz以下の低周波、プロペラ振動は20Hz以上の高周波に現れます。この境界を信号処理で自動検出し、Gyroflowの内部ロジックに合わせてパラメータに変換しています。

インストール

macOSの場合はHomebrewでインストールできます。

brew install gyrotriage

Rustの開発環境がある場合はcargoからもインストールできます。

cargo install --path .

使い方

基本的な使い方はMP4ファイルを渡すだけです。

gyrotriage DJI_0001.MP4

以下のようなテキスト出力が得られます。

File:        DJI_20260228080801_0003_D.MP4
Duration:    30.3s (60593 samples @ 2000Hz)
Score:       100 / 100
Level:       SEVERE
RMS:         34.8 °/s
Peak:        644.0 °/s
Pitch:       avg=1.4°/s  std=2.2°/s  max=47.9°/s
Roll:        avg=11.7°/s  std=13.5°/s  max=251.1°/s
Yaw:         avg=3.3°/s  std=4.4°/s  max=89.0°/s
---
Gyroflow plugin (Adjust parameters):
  Smoothness:           21
  Zoom limit:           118
  FOV:                  1.000
  Integration method:   None
  Lens correction:      100

末尾の「Gyroflow plugin (Adjust parameters)」ブロックが、Gyroflow OpenFXプラグインの「Adjust parameters」パネルにそのまま入力できる推奨値です。~~最後の2行がGyroflowに入力する推定パラメータです。~~ このうちSmoothnessとZoom limitはモーション解析から算出した値、Integration methodとLens correctionはDJI機の特性に基づく固定推奨です。この値をプラグインのパネルに入力すれば、そこから微調整を始められます（2026-06-04更新）。

なお旧スタンドアロンアプリ版では、末尾の出力が ~~Gyroflow: smoothness=21% max=0.300s max@hv=0.030s zoom_limit=118% zooming_speed=2.6s~~ という5値の形式でした。

HUD表示で直感的にブレを把握する

--visual オプションを付けると、ブレの特性をHUD風のグラフィックで表示します。

gyrotriage DJI_0001.MP4 --visual

冒頭のカバー画像がHUD出力の実例です。画面には以下の情報が表示されます。

スコアゲージ: ブレの重大度を0〜100で表示（STABLE / MILD / MODERATE / SEVEREの4段階）
レーダーチャート: Pitch・Roll・Yawの3軸でブレの偏りを可視化
ライングラフ: 合成角速度と各軸の角速度の時系列変化
推定パラメータ: ~~Gyroflowに入力する5つの値~~Gyroflow OpenFXプラグインに入力する推奨値

数値だけでは分かりにくい「このクリップはRoll方向のブレが支配的」「後半に激しいブレが集中している」といった特性が一目で把握できます。Gyroflowプラグインを適用する前に、どのクリップにどの程度の処理が必要かをトリアージするのに役立ちます。

HUD画像はPNGファイルとしても出力できます。

gyrotriage DJI_0001.MP4 --output-image shake.png

WezTermやiTerm2などSixel/iTerm2プロトコルに対応したターミナルでは --visual でインライン表示されます。非対応のターミナルでは --output-image でファイル出力してください。

テキストのみの環境向けには --sparkline オプションもあります。

gyrotriage DJI_0001.MP4 --sparkline

スコアの読み方

gyrotriageはブレの重大度を0〜100のスコアで表示します。

レベル	スコア	目安
STABLE	0〜25	ブレはほぼなし。スタビライズ不要
MILD	26〜50	軽微なブレ。スタビライズは任意
MODERATE	51〜75	目に見えるブレ。Gyroflow推奨
SEVERE	76〜100	激しいブレ。Gyroflow必須

DJI Air 3Sのような3軸ジンバル搭載機ではほぼSTABLEになりますが、DJI Neoのような1軸ジンバル機やAvataシリーズでアクロバティックな飛行をした場合はMODERATE〜SEVEREになることが多いです。

推定パラメータの使い方

~~出力された5つのパラメータはGyroflowのUIに直接入力できます。~~出力された推奨値はGyroflow OpenFXプラグインの「Adjust parameters」パネルに直接入力できます（2026-06-04更新）。

~~Gyroflowでクリップを開く~~DaVinci ResolveのタイムラインでクリップにGyroflowプラグインを適用する
出力された値をそれぞれのスライダーに入力する
プレビューで確認し、必要に応じて微調整する

このとき、Integration methodはNone、Lens correctionは100、FOVは1.0を起点にします。DJI機はクォータニオンを記録済みなので再積分が不要で、正しいレンズプロファイルを読み込めばフル補正で問題ないためです。

推定値はあくまで調整の出発点です。ブレが残っている場合はSmoothnessを上げる、カメラワークが鈍く感じる場合はSmoothnessを下げる、といった微調整で仕上げてください。ゼロからスライダーを動かして探るよりも、妥当な出発点があるだけで調整時間は大幅に短縮できます。

対応機体と撮影条件

モーションデータがMP4へ埋め込まれるDJI機種に対応しています。ただし撮影時の設定次第ではモーションデータが記録されないため、注意が必要です。

機体	条件
DJI Avata / Avata 2	EIS（Rocksteady）オフ、FOV Wide
DJI Neo / Neo2	アスペクト比4:3（EISは自動的にオフ）

Avataシリーズの場合、Rocksteadyをオンにしているとモーションデータが記録されません。Gyroflowで後処理する前提なら、撮影時はRocksteadyオフ・FOV Wideで撮影してください。

DJI Neoの場合、16:9で撮影するとモーションデータが記録されません。4:3で撮影する必要があります。

DJI Air 3Sなど3軸ジンバル搭載機はGyroflow自体を必要としないケースが多く、対象外としています。

実際の効果

gyrotriageで推定したパラメータを微調整なしでそのままGyroflow OpenFXプラグインに適用した映像（右）と、オリジナルの未処理映像（左）の比較です。

注意事項

推定値は信号処理に基づく客観的な算出であり、映像の主観的な品質評価は含まない
非常にゆっくりしたブレ（0.3Hz未満）は意図した動きと区別できない
GyroflowのDefaultアルゴリズムを前提としており、Plain 3Dや軸別モードでは推定値の解釈が異なる
極端に短いクリップ（2秒未満）では推定精度が低下する
商用空撮など業務用途では、必ずGyroflowのプレビューで結果を検証すること

Gyroflow. 「Gyroflow - Video stabilization using gyroscope data」

もしかしてだけど、あれって日本最古のアスキーアートだったんじゃないの？

2026-02-21T00:00:00+00:00

はじめに

左の画像はMidjourneyで生成したものです

1986年、パソコン通信は黎明期でASCIInetがまだ実験運用の時代でした。その頃の私はグラフィック（おそらくモノクロの有名歌手の画像）を自作プログラムでASCII文字の絵にして、あるパソコン通信のBBS（電子掲示板）に投稿しました。

あれから約40年。当時のアルゴリズムをGoで再実装し、CLIツール img2char として公開しました。

この記事では、当時の背景と img2char のアルゴリズムを紹介します。

1986年のパソコンとBBS

1986年はPC-VAN（1986年4月実験開始）やNIFTY-Serve（1987年4月開始）が立ち上がり始めた、日本のパソコン通信黎明期です。アスキーネット（ASCII-NET）は前年の1985年5月に実験サービスを開始しており、草の根BBSも各地で産声を上げていました。通信速度は300bpsから1200bps。BBSに書き込めるのはテキストだけの時代でした。グラフィックスを書き込むなんてとんでもない時代でした^[1]。

当時のパソコンのグラフィック事情も触れておきます。1986年時点では、画像をファイルとして保存・交換する汎用フォーマットはまだ普及していませんでした。グラフィックを描くといえば、BASICのLINE文やPAINT文を使ってプログラムとして記述するのが主流です。私自身、PAINT文を使わずに画像の上端から下端まで（縦200ドットしかない画面です）をLINE文だけで1ラインずつ塗りつぶし、モノクロ画像を描くことに当時凝っていました。グラフィックは「描く」ものであって「ファイルで送る」ものではなかったのです。

しかもBASICは機種ごとに方言が異なり、あるマシンで書いたプログラムが別のマシンでそのまま動くことはまずありません。グラフィック描画プログラムをBBSで流通させるのも現実的ではありませんでした。

そこで思いついたのが、「ASCII文字絵にすれば遅いパソコン通信でも送れるんじゃね？」です。

Sharp X1 ── 骨の髄までハードを極めたマシン

Sharp X1は1982年に発売された8ビットパソコンです。テレビ事業で培ったシャープの技術が随所に活かされた、ハードウェア設計の塊のようなマシンでした。

当時のZ80 CPUはメモリ空間が64KBしかなく、NECのPC-8801などではこの空間にメインRAMとグラフィックVRAM（GVRAM）を重ねて配置し、バンク切り替えでアクセスしていました。一方X1は、Z80のI/O命令が実行時にアドレスバスの上位8ビット（A8〜A15）にもレジスタの値を出力するという、公式マニュアルには記載されているものの目立たない仕様を活用しました。I/O空間を実質64KBに広げ、そこにGVRAMを配置したのです。メモリ空間64KBは丸ごとRAMとして使え、GVRAMへはI/O命令で直接アクセスできます。

この設計のおかげで、BASICからでもグラフィックVRAM上の画像データを読み出すことができました。グラフィックVRAM上の画像を8x8ドット単位で読み取り、キャラクタROMの各文字パターンと比較する。一致度が最も高い文字を選ぶ。このアルゴリズムをBASICで実装しました^[2]。

アルゴリズムの現代版 ── img2char

img2char は、あの当時のアルゴリズムをGoで忠実に再現したCLIツールです。処理は3段階で構成されています。

フォントパターンの準備 ── 95個のASCII印字可能文字の8x8ビットマップを用意する
画像のブロック分割 ── 入力画像を8x8ピクセルのブロックに分割する
パターンマッチング ── 各ブロックとフォントパターンのハミング距離を計算し、最も近い文字を選ぶ

フォントテーブルの構築

95個の印字可能ASCII文字（スペース 0x20 からチルダ 0x7E まで）について、それぞれ8x8ドットのビットマップパターンを持っています。

// font8x8Basic contains 8x8 bitmap patterns for 95 printable ASCII characters (0x20–0x7E).
var font8x8Basic = [95][8]byte{
    // 0x20 ' '
    {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
    // 0x21 '!'
    {0x18, 0x3C, 0x3C, 0x18, 0x18, 0x00, 0x18, 0x00},
    // 0x22 '"'
    {0x36, 0x36, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
    // ... 95文字分のパターンが続く
    // 0x41 'A'
    {0x0C, 0x1E, 0x33, 0x33, 0x3F, 0x33, 0x33, 0x00},
    // 0x7E '~'
    {0x6E, 0x3B, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
}

各バイトが8x8ビットマップの1行に対応し、LSB（最下位ビット）が左端のピクセルです。たとえば A のパターンを展開すると、以下のようになります。

(2進数はLSB=左端ピクセルから表記)
0x0C = 00110000 → ..##....
0x1E = 01111000 → .####...
0x33 = 11001100 → ##..##..
0x33 = 11001100 → ##..##..
0x3F = 11111100 → ######..
0x33 = 11001100 → ##..##..
0x33 = 11001100 → ##..##..
0x00 = 00000000 → ........

8バイトで1文字の形が表現されています。高速な比較のため uint64 にパックします。

func packFont(pattern [8]byte) uint64 {
    var v uint64
    for i := 0; i < 8; i++ {
        v |= uint64(pattern[i]) << (i * 8)
    }
    return v
}

X1に搭載されていたHu-BASICの整数型は16ビット（2バイト）なので、当時は8バイトのパターンを2バイトずつ4回のXORループで比較していました。現代のGoでは8バイトを1つの64ビット整数に詰め込むことで、後述のXOR演算が一発で実行できます。

8x8ブロックとフォントパターンの照合

ここが核心部分です。画像から切り出した8x8ブロックを、95文字すべてのフォントパターンと比較し、最も「形が近い」文字を見つけます。

func matchChar(block [8]byte, fontTable [95]uint64) byte {
    blockVal := packBlock(block)
    bestDist := 65 // max possible is 64
    bestIdx := 0
    for i := 0; i < 95; i++ {
        dist := bits.OnesCount64(blockVal ^ fontTable[i])
        if dist < bestDist {
            bestDist = dist
            bestIdx = i
        }
    }
    return byte(0x20 + bestIdx)
}

blockVal ^ fontTable[i] のXOR演算で、ブロックとフォントパターンのビットが異なる位置を検出します。bits.OnesCount64 でその異なるビット数（ハミング距離）を数えます。64ビット中の不一致ビット数が最小の文字を選ぶ、シンプルかつ強力な方式です。

使い方

入力画像は640x200または320x200ピクセルの二値化済みPNGである必要があります。前処理用のシェルスクリプトが付属しています。

# 前処理（ImageMagickでリサイズ＋二値化）
./convert.sh input.jpg 640 200

# ASCII文字に変換
img2char input_640x200.png

640x200の画像は80x25文字、320x200なら40x25文字に変換されます。当時は320x200モードの40x25文字でやっていました。

今回、同じロジックで似たような画像を変換してみましたが、なかなかいけています（冒頭の画像を参照）。

もしかして......日本最古のASCII Artなんじゃないの？

当時の変換結果をパソコン通信のBBSに投稿したところ、ちょっとした話題になりました。テキストしか表示できない端末に、文字だけで画像が浮かび上がるのですから、当時としては驚きだったようです。40x25文字分の解像度しかありませんが、元の画像の輪郭や特徴が文字の組み合わせで再現される様子は、見た人を楽しませるものでした。

ここで少し大胆なことを言わせてください。

文字で画像を表現する試み自体は古く、1898年のタイプライターアートにまで遡ります。コンピューターによる自動変換も、1967年にベル研究所のケネス・ノウルトンがIBM 7094で実現しています。ただしそれは巨大なメインフレームでの話です。

日本に目を向けると、記録に残る最古の「アスキーアート」は1986年6月20日にアスキーネット上で若林泰志が投稿した顔文字 (^_^) とされています。2ちゃんねるでAAが花開くのは1999年以降。1986年当時、手作業でAA（アスキーアート）を描く文化はまだ広まっていませんでした。

そんな時代に、8ビットパソコンで画像をASCII文字に変換してBBSに投稿していたわけです。

もしかして、もしかしてだけど、これって日本最古のアスキーアートなんじゃないの？（どぶろっく風）

......まあ、証拠は当時のBBSのログとともに電子の海に消えてしまいましたが。

まとめ

img2char は、1986年のSharp X1で生まれたアイデアを現代のGoで再実装したツールです。

当時のパソコン通信の制約（テキストのみ）が生んだ発想
PCGという強力なハードウェアをあえて使わず、ASCII文字だけで勝負した選択
8x8ドットブロックとフォントパターンのハミング距離による照合という、シンプルだが効果的なアルゴリズム

40年前のBASICプログラムが64ビット整数のXOR演算に姿を変えても、やっていることは同じです。画像の形を文字の形で近似する。それだけのことが、なぜか人を惹きつけます。

興味を持っていただけたら、ぜひ試してみてください。

参考

アスキーアート - Wikipedia -- 日本におけるアスキーアートの歴史、顔文字の起源
ASCII art - Wikipedia (English) -- タイプライターアート（1898年）からの世界的な歴史
The history of ASCII Art - ASCII Art Archive -- ベル研のノウルトン（1967年）による自動変換の歴史
X1 (コンピュータ) - Wikipedia -- Sharp X1のハードウェア仕様
Z80の16ビットI/Oアドレスについての考察（大石氏）-- Z80のI/O命令が16ビットアドレスを出力する仕様の解説（サイト閉鎖）
パーソナルなコンピュータのメモリ事情（第3回：8ビット中期）- Electrelic -- X1とPC-8801のGVRAM配置方式の比較
パソコン通信の歴史 - 木暮仁 -- PC-VAN、NIFTY-Serve、草の根BBSの歴史

そもそも画像をファイルに書き出すフォーマットさえ標準的なものはなかった。 ↩
X1にはPCG（Programmable Character Generator）が搭載されており、文字のフォントパターンを自由に書き換えられました。任意のドットパターンを「文字」として表示でき、グラフィックスに近い表現が可能でした。しかしBBSに投稿するならPCGは使えません。相手の画面にPCGのデータは存在せず、表示できるのは標準のASCII文字だけだからです。 ↩

多機能Todoに疲れた人へ ─「一枚の紙」だけのタスク管理CLI

2026-01-23T00:00:00+00:00

Table of Contents

はじめに

ターミナルで作業中、ふと「あれもやらなきゃ」と思いついたとき、頭の中を書き出す場所が欲しくなります。物理的なメモ用紙ならすぐに書けますが、ターミナルから手を離すのは煩わしい。かといって多機能なTodoアプリを開くと、プロジェクトやタグを考えているうちに書きたかったことを忘れてしまう。

そこで作ったのが Tiny Task Tool です。コマンド名はタイプしやすいように ttt としました。

「一枚の紙」のシンプルさをターミナルで再現することを目指した、ミニマルなタスク管理ツールです。

この記事では、ttt のコンセプトと使い方を紹介しつつ、Claude Codeとの協働開発でドキュメント駆動とTDDがいかに効果的だったかをお伝えします。

Tiny Task Tool とは

ttt(Tiny Task Tool) は「デジタルなメモ用紙」を目指したTUIタスク管理ツールです。

主な特徴

一枚の紙: ファイルは常に1つ。「どのファイルに書こう」という選択を排除
今に集中: タスクをすぐ書き出し、完了したらアーカイブ。シンプルな運用
ノード指向: 階層構造のタスクを直感的に扱える。親を完了すれば子も完了
Unix 哲学: フォーカス機能以外は外部エディタやGitに任せる

インストール

# go install（推奨）
go install github.com/yostos/tiny-task-tool@latest

# Homebrew
brew install yostos/tap/ttt

基本的な使い方

ターミナルで ttt と打つだけで、1ページのタスク表がTUIで開きます。

ttt                    # TUIでタスク表を開く
ttt -t "牛乳を買う"     # コマンドラインからタスクを追加
ttt sync               # git pushでリモートと同期

TUIでは e でエディタを開き、a でアーカイブ、q で終了。キーバインドはVim/Emacsユーザー向けにカスタマイズ可能です。

タスクのフォーマット

シンプルなMarkdownチェックボックス形式です。

- [ ] 未完了のタスク
- [x] 完了したタスク @done(2026-01-18)
  - [x] 子タスクも自動で完了 @done(2026-01-18)

タスク以外の箇条書きもノードとして挿入できます。タスクをグルーピングするためにセクション（# Task や ## Project A）なども扱えます。

完了したタスクには自動で @done(日付) タグが付き、設定した日数が経過するとarchive.mdに移動します。

なぜ作ったのか

きっかけはZennで見かけた「Markdown Paper という選択肢」という記事でした。ephe.app の「一枚の紙」コンセプトをCLIに持ち込んだ aeph の紹介記事です。

コンセプトには共感しましたが、aephは複数ファイルに対応しており、「一枚の紙」とは少し違うと感じました。そこでaephのソースコードを参考にするのではなく、ゼロから自分のコンセプトで作ることにしました。

既存のツールにも同様の問題がありました。

Todo アプリ: 多機能すぎる。プロジェクト、優先度、タグ…考えているうちに書きたいことを忘れる
Markdown エディタ: ファイル名やフォルダを考える必要がある
GUI アプリ: ターミナルから離れるコンテキストスイッチが発生する

単一ファイル、選択肢なし、気を散らすものなし。机の上のメモ用紙のように、「開いて、書いて、終わったら消す」だけの体験が欲しかったのです。

Claude Code との開発体験

このプロジェクトはClaude Codeを活用し、以下のプロセスで開発しました。

コンセプト文書化（concept.md）
詳細仕様策定（specification.md）
アーキテクチャ選定（architecture.md）
テストコード先行開発
実装
テスト自動化

ドキュメント駆動が効いた理由

Claude Codeとの協働で最も効果的だったのは、まずドキュメントを書き、それに従って開発するアプローチでした。

1. concept.md で方向性を固める

最初に「なぜ作るのか」「何をしないか」を明確にしました。

### やらないこと

- ファイル指定（「どのファイルを開くか」という選択を排除）
- 複数ファイル管理（一枚の紙の原則に反する）
- ファイル内編集（外部エディタに任せる）

「やらないこと」を明文化したことで、開発中に機能追加の誘惑が来ても「concept.mdに反する」と判断できました。Claudeにも「この機能はconcept.mdの方針に反しますね」とフィードバックを受けられます。

2. specification.md で仕様を詳細化

ユースケース、画面レイアウト、エラー処理まで事前に定義しました。これによりClaudeへの指示が明確になり、生成されるコードの品質が上がりました。

3. architecture.md で技術選定を記録

「なぜその技術を選んだか」「他の選択肢をなぜ却下したか」を記録しました。後から見返したとき、またClaudeに文脈を伝えるときに役立ちました。基本的に記載方法は Architectural Decision Record（ADR）形式 を採用して記載しています。

以下は言語選定の際の例です。

候補	却下理由
Rust	学習コストが高い。所有権/ライフタイムの概念が独特で、AI 駆動開発でコンパイルエラー修正時に堂々巡りするリスク
Python	PEP 668 により配布が複雑化。起動速度も遅い
TypeScript	単一バイナリ配布ができず「摩擦をなくす」原則に反する

TDD が AI 駆動開発と相性が良い理由

テスト駆動開発（TDD）はClaude Codeとの開発で特に威力を発揮しました。

テストファーストのメリット

期待動作の明確化: テストコードが「仕様書」として機能し、開発前に私が確認できるためClaudeへの指示が曖昧にならない
リグレッション防止: AIが生成したコードの変更が既存機能を壊していないか即座に確認
リファクタリングの安心感: テストが通れば安心して改善できる

実際の開発フロー

# 1. まずテストを書く（Red）
$ go test ./...
# FAIL: TestArchiveCompletedTasks - 期待する動作のテストが失敗

# 2. Claude に実装を依頼
# 「このテストを通す実装をお願いします」

# 3. テストが通ることを確認（Green）
$ go test ./...
# PASS

# 4. リファクタリング
# 「この実装をより読みやすくリファクタリングしてください」

特に階層タスクのアーカイブ処理のような複雑なロジックでは、テストケースを先に書いておくことで、エッジケースの考慮漏れを防げました。

Claude Code との対話で心がけたこと

ドキュメントを参照させる:「concept.mdの方針に従って」「specification.mdの仕様通りに」
小さな単位で依頼: 一度に多くを頼まず、テスト→実装→確認のサイクルを回す
コミットを細かく: 動作確認できた時点でコミット。戻れるポイントを作る

技術スタック

分野	選択	理由
言語	Go	単一バイナリ配布、高速起動
TUI	bubbletea + lipgloss	成熟したエコシステム、Elm アーキテクチャ
設定	pelletier/go-toml v2	TOML 1.0 準拠、高速
テスト	testing + testify	標準+簡潔なアサーション

まとめ

ttt は「一枚の紙」という思想にこだわった結果、機能を削ることで価値を磨けたツールになったと思います。私自身も便利に使っています。もっと高機能なツールはたくさんありますが、コンセプトに賛同いただける多くの方に使ってもらえれば幸いです。

Claude Codeとの開発では、ドキュメント駆動 と TDD の組み合わせが非常に効果的でした。

ドキュメント駆動: 要件だけでなく方針を文書化するところから、Claude Codeと協働する
TDD: 期待動作を定義し、品質を担保する

「Claude Codeに任せきり」ではなく「Claude Codeと協働する」開発スタイルとして、このアプローチはおすすめできます。

興味を持っていただけたら、ぜひ使ってみてください。

https://github.com/yostos/tiny-task-tool

この記事で紹介したドキュメント（concept.md, specification.md, architecture.md）は GitHub リポジトリの docs/ ディレクトリで公開しています。

Logic ProのAIFファイルをラウドネス正規化してFLACに変換するスクリプト

2026-01-14T00:00:00+00:00

INFO

この記事の公開後、Waves L4 Ultramaximizerでマスタリングするようになり、現在はこのスクリプトを使っていません。理由と、それでもこのスクリプトが役に立つ場面を末尾の追記にまとめました。

背景

Logic Proでバウンスした音声ファイル(Aiff)をFLACに変換する際、適切な音量に正規化する必要があります。ffmpegのloudnormフィルタを使うと高品質なラウドネス正規化が可能ですが、最良の結果を得るには2パス処理が推奨されます。

この2パス処理は以下のような手順です。

1回目の実行で音声のラウドネス値を測定
測定された値を確認し、手動で2回目のコマンドにコピー
2回目の実行で測定値を使用して正規化を適用

毎回この作業を手動で行うのは面倒なので、自動化するスクリプトを作成しました。

スクリプトの内容

以下は公開後に改訂したコードです。改訂の内容は末尾の追記にまとめました。Gistでも公開しています。

#!/bin/bash

# Script to convert AIF files to FLAC
# By default, performs pure format conversion without any audio processing,
# then verifies that the FLAC decodes back to bit-identical PCM.
# Use -n/--normalize to apply EBU R128 loudness normalization; that mode
# refuses to run unless it can be done as a pure gain change (linear mode).
#
# Copyright (c) 2026 yostos
# Licensed under the MIT License
# https://opensource.org/licenses/MIT

set -e

VERBOSE=false
NORMALIZE=false
VERIFY=true
ALLOW_DYNAMIC=false

# Loudness targets. Used for BOTH the measurement pass and the encoding pass;
# they must match, otherwise loudnorm's target_offset is computed against a
# different target than the one actually applied.
TARGET_I=-14
TARGET_TP=-1
TARGET_LRA=11

usage() {
    echo "Usage: $0 [-v|--verbose] [-n|--normalize] [--no-verify] [--allow-dynamic] <input_file.aif>"
}

# Parse options
while [[ $# -gt 0 ]]; do
    case $1 in
        -v|--verbose)
            VERBOSE=true
            shift
            ;;
        -n|--normalize)
            NORMALIZE=true
            shift
            ;;
        --no-verify)
            VERIFY=false
            shift
            ;;
        --allow-dynamic)
            ALLOW_DYNAMIC=true
            shift
            ;;
        -h|--help)
            usage
            echo ""
            echo "Options:"
            echo "  -v, --verbose      Show detailed ffmpeg output"
            echo "  -n, --normalize    Apply EBU R128 loudness normalization (two-pass)"
            echo "      --no-verify    Skip the bit-exactness check in conversion mode"
            echo "      --allow-dynamic  Permit loudnorm's dynamic mode (alters dynamics)"
            echo "  -h, --help         Show this help message"
            echo ""
            echo "By default, performs pure format conversion (AIF -> FLAC) without"
            echo "any audio processing, and verifies the result is bit-identical to"
            echo "the source. Use -n to apply loudness normalization."
            echo ""
            echo "Normalization is only performed when loudnorm can run in linear"
            echo "mode (a single constant gain). If the requested target cannot be"
            echo "reached without compression/limiting, the script aborts instead of"
            echo "silently degrading the audio. Use --allow-dynamic to override."
            exit 0
            ;;
        -*)
            echo "Error: Unknown option $1"
            usage
            exit 1
            ;;
        *)
            INPUT_FILE="$1"
            shift
            ;;
    esac
done

if [ -z "$INPUT_FILE" ]; then
    usage
    echo "Use -h or --help for more information"
    exit 1
fi

if [ ! -f "$INPUT_FILE" ]; then
    echo "Error: File '$INPUT_FILE' not found"
    exit 1
fi

# Generate output filename (change extension to .flac)
OUTPUT_FILE="${INPUT_FILE%.*}.flac"

# Run ffmpeg, capturing output so errors can be reported.
# NOTE: `set -e` aborts the shell on a failing command substitution before the
# next line runs, so $? must be captured with `set +e` around the assignment.
FFMPEG_OUTPUT=""
FFMPEG_EXIT_CODE=0
run_ffmpeg() {
    if [ "$VERBOSE" = true ]; then
        # Tee to a temp file so the output is still available for the
        # post-encode checks below while being shown live.
        local tmplog
        tmplog=$(mktemp)
        set +e
        ffmpeg "$@" 2>&1 | tee "$tmplog"
        FFMPEG_EXIT_CODE=${PIPESTATUS[0]}
        set -e
        FFMPEG_OUTPUT=$(cat "$tmplog")
        rm -f "$tmplog"
    else
        set +e
        FFMPEG_OUTPUT=$(ffmpeg -hide_banner "$@" 2>&1)
        FFMPEG_EXIT_CODE=$?
        set -e
    fi
    if [ $FFMPEG_EXIT_CODE -ne 0 ]; then
        echo "Error during encoding (exit code: $FFMPEG_EXIT_CODE)"
        [ -n "$FFMPEG_OUTPUT" ] && echo "$FFMPEG_OUTPUT"
        exit 1
    fi
}

# Decode both files to a common 32-bit format and compare hashes.
# `-f md5` alone defaults to pcm_s16le, which would compare only the top 16
# bits and report a false match, so the codec must be pinned explicitly.
verify_lossless() {
    local src="$1" dst="$2" a b
    echo "=== Verifying bit-exactness... ==="
    set +e
    a=$(ffmpeg -v error -i "$src" -c:a pcm_s32le -f md5 -)
    local rc_a=$?
    b=$(ffmpeg -v error -i "$dst" -c:a pcm_s32le -f md5 -)
    local rc_b=$?
    set -e
    if [ $rc_a -ne 0 ] || [ $rc_b -ne 0 ]; then
        echo "Error: verification failed to decode one of the files"
        exit 1
    fi
    if [ "$a" = "$b" ]; then
        echo "  OK: output is bit-identical to the source (${a#MD5=})"
    else
        echo "  FAILED: output does NOT match the source"
        echo "    source: ${a#MD5=}"
        echo "    output: ${b#MD5=}"
        echo "  The FLAC encoder supports 16- and 24-bit only; a 32-bit float"
        echo "  source cannot be stored losslessly and will fail this check."
        exit 1
    fi
    echo
}

if [ "$NORMALIZE" = true ]; then
    # === Loudness normalization mode (two-pass) ===

    # Detect input sample rate so it is preserved through the loudnorm filter.
    # loudnorm operates internally at 192kHz in dynamic mode and would
    # otherwise force the output to 192kHz, so pin the output rate explicitly.
    INPUT_SR=$(ffprobe -v error -select_streams a:0 \
        -show_entries stream=sample_rate -of csv=p=0 "$INPUT_FILE")
    if [ -z "$INPUT_SR" ]; then
        echo "Error: Could not determine input sample rate"
        exit 1
    fi

    echo "=== Step 1: Measuring loudness... ==="
    echo

    # Measure with the same targets used for encoding.
    LOUDNESS_JSON=$(ffmpeg -i "$INPUT_FILE" \
        -af "loudnorm=I=$TARGET_I:TP=$TARGET_TP:LRA=$TARGET_LRA:print_format=json" \
        -f null - 2>&1 | grep -A 12 "Parsed_loudnorm")

    # Extract required values from JSON
    MEASURED_I=$(echo "$LOUDNESS_JSON" | grep '"input_i"' | awk -F'"' '{print $4}')
    MEASURED_TP=$(echo "$LOUDNESS_JSON" | grep '"input_tp"' | awk -F'"' '{print $4}')
    MEASURED_LRA=$(echo "$LOUDNESS_JSON" | grep '"input_lra"' | awk -F'"' '{print $4}')
    MEASURED_THRESH=$(echo "$LOUDNESS_JSON" | grep '"input_thresh"' | awk -F'"' '{print $4}')
    TARGET_OFFSET=$(echo "$LOUDNESS_JSON" | grep '"target_offset"' | awk -F'"' '{print $4}')

    if [ -z "$MEASURED_I" ] || [ -z "$MEASURED_TP" ] || \
       [ -z "$MEASURED_LRA" ] || [ -z "$MEASURED_THRESH" ]; then
        echo "Error: Could not parse loudnorm measurement output"
        exit 1
    fi

    echo "Measurement results:"
    echo "  Input Integrated: $MEASURED_I LUFS"
    echo "  Input True Peak:  $MEASURED_TP dBTP"
    echo "  Input LRA:        $MEASURED_LRA LU"
    echo "  Input Threshold:  $MEASURED_THRESH LUFS"
    echo "  Target Offset:    $TARGET_OFFSET LU"
    echo

    # Predict whether loudnorm can stay in linear mode (constant gain, no
    # compression, no limiting, no 192kHz resample round-trip). It falls back
    # to dynamic mode when the gain would push the true peak past the ceiling,
    # when the threshold is unmeasurable, or when measured_LRA is exactly 0
    # (loudnorm reads 0 as "not supplied" and disables linear mode).
    LINEAR_CHECK=$(awk -v i="$MEASURED_I" -v tp="$MEASURED_TP" \
                       -v lra="$MEASURED_LRA" -v th="$MEASURED_THRESH" \
                       -v ti="$TARGET_I" -v ttp="$TARGET_TP" 'BEGIN {
        offset_tp = tp + (ti - i);
        max_i     = ti - (offset_tp - ttp);
        ok = (lra > 0) && (th > -70) && (offset_tp <= ttp);
        printf "%d %.2f %.2f", ok, offset_tp, max_i;
    }')
    LINEAR_OK=$(echo "$LINEAR_CHECK" | awk '{print $1}')
    PREDICTED_TP=$(echo "$LINEAR_CHECK" | awk '{print $2}')
    MAX_LINEAR_I=$(echo "$LINEAR_CHECK" | awk '{print $3}')

    if [ "$LINEAR_OK" != "1" ] && [ "$ALLOW_DYNAMIC" != true ]; then
        echo "Error: this file cannot be normalized to $TARGET_I LUFS by gain alone."
        if awk -v l="$MEASURED_LRA" 'BEGIN {exit !(l <= 0)}'; then
            echo "  Measured LRA is 0.00 LU, which loudnorm treats as unset and"
            echo "  which forces its dynamic (compressing) mode."
        elif awk -v t="$MEASURED_THRESH" 'BEGIN {exit !(t <= -70)}'; then
            echo "  Measured threshold ($MEASURED_THRESH LUFS) is too low to measure reliably."
        else
            echo "  The required gain would raise true peak to $PREDICTED_TP dBTP,"
            echo "  above the $TARGET_TP dBTP ceiling, so loudnorm would silently switch"
            echo "  to its dynamic mode and apply compression and limiting."
            echo "  The loudest linear-safe target for this file is $MAX_LINEAR_I LUFS."
        fi
        echo "  Aborting to leave the master untouched."
        echo "  Convert without -n, or pass --allow-dynamic to override."
        exit 1
    fi

    if [ "$LINEAR_OK" = "1" ]; then
        echo "Linear (gain-only) normalization is possible; predicted output true peak: $PREDICTED_TP dBTP"
    else
        echo "WARNING: --allow-dynamic given; loudnorm will compress and limit this file."
    fi
    echo

    echo "=== Step 2: Encoding to FLAC with normalization... ==="
    echo

    # Encode to FLAC using measured values.
    # Note: in linear mode loudnorm ignores `offset` and recomputes it from the
    # measured values; it is passed for the --allow-dynamic path.
    run_ffmpeg -y -i "$INPUT_FILE" \
        -af "loudnorm=I=$TARGET_I:TP=$TARGET_TP:LRA=$TARGET_LRA:measured_I=$MEASURED_I:measured_TP=$MEASURED_TP:measured_LRA=$MEASURED_LRA:measured_thresh=$MEASURED_THRESH:offset=$TARGET_OFFSET:linear=true:print_format=summary" \
        -ar "$INPUT_SR" -c:a flac -compression_level 8 "$OUTPUT_FILE"

    if [ "$VERBOSE" != true ]; then
        echo "$FFMPEG_OUTPUT" | grep -A 15 "Input Integrated:" | grep -v "^\[" | grep -v "^$" || true
        echo
    fi

    # Confirm loudnorm actually stayed linear; it downgrades silently.
    if echo "$FFMPEG_OUTPUT" | grep -q "Normalization Type:[[:space:]]*Dynamic"; then
        if [ "$ALLOW_DYNAMIC" != true ]; then
            echo "Error: loudnorm fell back to dynamic mode despite the pre-flight check."
            echo "  The output has been compressed and limited; removing it."
            rm -f "$OUTPUT_FILE"
            exit 1
        fi
        echo "WARNING: dynamic mode was used; dynamics have been altered."
    fi
else
    # === Pure conversion mode (default) ===
    echo "=== Converting to FLAC... ==="
    echo

    # No filters and no -sample_fmt: ffmpeg carries 16-bit through as 16-bit
    # and 24-bit through as 24-bit. -compression_level only trades encode time
    # for file size; the decoded samples are identical at every level.
    run_ffmpeg -y -i "$INPUT_FILE" -c:a flac -compression_level 8 "$OUTPUT_FILE"

    if [ "$VERIFY" = true ]; then
        echo
        verify_lossless "$INPUT_FILE" "$OUTPUT_FILE"
    fi
fi

echo
echo "=== Completed ==="
echo "Output file: $OUTPUT_FILE"

# Display file sizes
if command -v du &> /dev/null; then
    INPUT_SIZE=$(du -h "$INPUT_FILE" | awk '{print $1}')
    OUTPUT_SIZE=$(du -h "$OUTPUT_FILE" | awk '{print $1}')
    echo "Input file:  $INPUT_SIZE"
    echo "Output file: $OUTPUT_SIZE"
fi

使い方

AIFファイルのパスを引数に指定して実行します。オプションを付けなければ、ラウドネスには手を加えずFLACに変換し、変換後の音声が元のファイルとビット単位で一致するかを検証します。

./aif2flac.sh input.aif

ラウドネス正規化をする場合は-nオプションを付けます。

./aif2flac.sh -n input.aif

ほかのオプションは次のとおりです。出力ファイルは同じディレクトリに.flac拡張子で保存されます。

-v: ffmpegの詳細な出力を表示する
--no-verify: 変換後の一致検証を省く
--allow-dynamic: loudnormのダイナミックモードでの処理を許可する（音のダイナミクスが変わる）

loudnormフィルタについて

ffmpegのloudnormフィルタは、EBU R128規格に基づいたラウドネス正規化を行うためのフィルタです。単純な音量の増減ではなく、人間の聴覚特性を考慮した知覚的な音量の均一化を実現します。

このスクリプトでは以下のパラメータを使用しています。

I=-14: 目標のIntegrated Loudness（LUFS単位）
TP=-1: True Peak値の上限（dBTP単位）
LRA=11: Loudness Range（LU単位）

I=-14 LUFSは、Spotify、YouTube Music、Apple Musicなどの主要なストリーミングサービスが採用している標準的なラウドネス基準です。世間一般で広く使われているこの基準を参考にすることで、適切な音量バランスを保つことができます。

1パス処理では入力音声の特性を考慮せずに正規化するため、音質劣化の可能性があります。2パス処理では、1回目で測定した入力音声の実際の値を2回目の処理に使用することで、より正確で高品質な正規化が可能になります。

まとめ

Logic Proから書き出した音声ファイルをFLACに変換する際の2パス処理を自動化することで、手動でパラメータをコピーする手間がなくなり、作業効率が大幅に向上しました。

今後は、複数ファイルの一括処理や、ターゲットラウドネス値のカスタマイズなどの機能を追加するかもしれません。

追記: L4 Ultramaximizer導入後にこのスクリプトをやめた理由と残る価値

この記事を書いた後、Logic ProのマスターにWaves L4 Ultramaximizerを入れ、ラウドネスとLRAをマスタリングの段階で作り込むようになりました。そうなると、このスクリプトがやっていることは「最終的に音量を-14 LUFSに合わせる一律のゲイン調整」だけになり、LRAの調整としてはほぼ意味がありません。場合によっては、マスタリングの結果を壊すおそれもあります。

理由はloudnormの動作にあります。2パスでlinear=trueを指定した場合、次の2つの条件を両方満たすときだけ、単純な一律ゲイン変更（線形モード）になります。

入力のLRAが指定値（LRA=11）以下である
ゲインを変えた後のTrue Peakが-1 dBTP以下に収まる

L4で仕上げた音源ならLRAはたいてい11 LU以下なので、LRA=11は条件の判定に使われるだけで、LRAそのものは変わりません。一方で条件を満たさない場合、loudnormは何も言わずにダイナミックモードへ切り替わり、独自のコンプレッションとリミッティングをかけます。これはL4での作業と二重処理になります。

そのため現在は、ラウドネスには手を加えず、形式だけを変換しています。FLACは可逆圧縮なので、L4で仕上げた結果がそのまま残ります。

ffmpeg -i xxxx.aiff -c:a flac -compression_level 8 xxxx.flac

マスタリング済みの音源に使う理由はなくなりましたが、このスクリプトの価値がまったくなくなったわけではありません。次のような場面では今でも役に立ちます。

リミッターを通していないバウンスやラフミックスを、手早く-14 LUFS前後にそろえたいとき
形式変換の結果が元の音声とビット単位で一致するかを確かめたいとき
loudnormの2パス処理を自動化する方法の例として参照したいとき

なお、スクリプトは公開後に次のように改訂しています。記事中のコードは改訂後のものです。

既定ではラウドネス正規化をせず、形式だけを変換する。変換後は、元のファイルとFLACをそれぞれデコードしたPCMのハッシュを比べ、ビット単位で一致するかを検証する
正規化は-nを付けたときだけ行う。測定値から線形モードで処理できないと見込んだ場合は、出力を作らずに中止する
正規化の後、サマリーのNormalization TypeがDynamicになっていれば、出力ファイルを削除してエラーで終了する
出力のサンプルレートを-arで入力と同じ値に固定する。ダイナミックモードでは出力が192 kHzにアップサンプリングされるため
FLACの圧縮レベルを最大の8にする。圧縮レベルで変わるのはエンコード時間とファイルサイズだけで、デコードした音声は同じになる

GitHub Actionsでnpmパッケージ公開を自動化する - Trusted Publishingで実現するトークンレス運用

2025-12-05T00:00:00+00:00

本記事では、私が開発しているjrnl-mcpパッケージで実装した、 GitHubが発表したnpmの認証強化対応の Trusted Publishing (OIDC) を使用したトークン管理不要の自動公開について記載しています。

npmの認証変更の背景

GitHubは2025年9月29日に、npmのセキュリティ強化として以下の変更を発表しました。

Classic Access Tokenの廃止
Trusted Publishing (OIDC) またはGranular Access Tokenへの移行推奨
より細かい権限管理の実現

移行先として2つの選択肢があります。

Granular Access Token
Trusted Publishing (OIDC)

Granular Access Tokenは、従来のトークン方式を改良したものでパッケージごとの権限管理が可能となっていますが、定期的なトークンのローテーションが必要です。 Trusted Publishingはトークンを完全に排除した新しい認証方式で、公開を自動化しトークンを完全に排除したものです。

jrnl-mcpでは、トークン管理の手間を完全に排除できる Trusted Publishing を採用しました。

自動公開の仕組み

全体のフロー

jrnl-mcpでは、以下のフローで自動公開を実現しています。

GitHubでリリースを作成
GitHub Actionsが自動起動
依存関係のインストールとテストを実行
npmへ自動公開

この仕組みにより、リリース作成だけでパッケージの公開が完了します。

GitHub Actionsの設定

実際に使用しているワークフロー設定は以下の通りです。

name: Publish to npm

on:
  release:
    types: [published]

permissions:
  contents: read
  id-token: write

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
          registry-url: "https://registry.npmjs.org"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm run test:ci

      - name: Publish to npm
        run: npm publish --provenance --access public

重要なポイントは、

GitHubのリリース機能を使用することで、手動でのトリガーが可能になる。これにより、意図しないタイミングでの公開を防ぐ。
permissionsの設定により、GitHub Actionsはnpmに対して一時的なOIDCトークンを発行・認証する。長期的なトークンをSecretに保存する必要がない。
npm publish --provenance --access publicにより自動的にprovenance（出所証明）が生成され、パッケージがどのリポジトリから公開されたか検証可能となる。
npm run test:ciにより公開前のテストを自動化する。

Trusted Publishing の設定方法

Trusted Publishingを使用する場合、npm側での設定が必要です。

1. npm でパッケージを公開

まず、通常の方法で初回のパッケージを公開します（トークンを使用）。npm側でパッケージが存在している必要があるためです。

2. npm で Trusted Publishing を設定

npm のパッケージ設定にアクセス
公開したパッケージの"Settings"タブを開く
"Publishing access"セクションで"Add a publisher"を選択
GitHub Actionsを選択し、以下を設定する
- Repository: <username>/<repository-name>（例: yostos/jrnl-mcp）
- Workflow: ワークフローファイル名（例: publish.yml）
- Environment: 未指定（デフォルト）または特定の環境名

3. GitHub Actions の設定

前述のワークフロー設定で、id-token: write 権限を付与するだけで完了です。トークンをSecretに保存する必要はありません。

トークンベースとの比較

Trusted Publishingを使用することで、以下の作業が不要になります。

npmトークンの作成と保存
GitHub Secretsへのトークン登録
トークンの定期的なローテーション（Granular Access Tokenの場合、最大90日ごと）
トークン漏洩のリスク管理

まとめ

Trusted Publishing (OIDC) とGitHub Actionsを使用したnpmパッケージの自動公開により、以下のメリットが得られました。

公開作業の効率化
トークン管理の完全な排除
セキュリティの向上
品質の担保
透明性の確保（自動provenance生成）

特に、Trusted Publishingの導入により、トークンの定期的なローテーションや漏洩リスクの心配が不要になり、セキュリティと運用性が大幅に向上しました。npmパッケージを公開している方は、ぜひTrusted Publishingへの移行とGitHub Actionsによる自動化を検討してみてください。

Granular Access Tokenでもセキュリティは向上しますが、定期的なローテーション（最大90日ごと）が必要なため、可能であればTrusted Publishingの使用を推奨します。

参考リンク

Apple Silicon時代のMacバックアップ最新戦略

2025-04-18T00:00:00+00:00

Macのバックアップ戦略

macOSはOS自体がTimeMachineという自動バックアップ機能を持っています。以下のような特徴を持っています。

特徴: macOSに標準搭載、独自形式でデータを保存
メリット: 設定が簡単、自動バックアップ、過去バージョンへのアクセス
デメリット: 独自形式のため通常のFinderからのアクセスが困難
アプローチ: 問題発生時はリカバリーからOSインストール後、Migration Assistantでデータ復元

iMacを使っていた時は使っていましたが、Macbookを使うようになってから TimeMachineの使用を止めました。理由は、バックアップ用にディスクが常にマウントされているとは限らないので「自動バックアップ」の恩恵が相対的に薄く、加えて独自形式のためTimeMachineのメカニズムでしかバップアップにアクセスできないためです。

Apple Silicon時代のバックアップの変化

TimeMachineを使用しない替わりに、長らくSuperDuper やCarbon Copy Clonerを使いディスクごと完全なクローンを取っていました。完全なクローンはブート可能なので、リカバリーの際にはクローンディスクから macOSをブートしてリカバリーを行うことができました。

しかし、Apple Silicon搭載のMac（M1/M2/M3チップ）ではIntelが使われていた時代と比較してシステムアーキテクチャが大きく変わりました。

主な変更点は次の通りです。

OSが読み取り専用として保護されるようになった
リカバリー機能がより強化された（Recovery・Fallback Recoveryが内蔵）
外部ドライブからの起動に制限が追加された

バックアップ戦略も見直す必要が出てきました。このためBootableな完全ディスククローンという戦略は以前ほど重要ではなくなりました。

推奨バックアップ戦略

次のようなバックアップ戦略を変更することが必要です。

データ中心のバックアップ:
- OSではなく、ユーザーデータを確実に保護する
- SuperDuperの場合はBackup - User filesオプションが効率的
- TimeMachineを使う場合は、同様にデータのバックアップに重点を置く
リカバリー戦略:
- 問題発生時：
  1. リカバリーモードから起動（⌘+Rキー）
  2. OSをクリーンインストール
  3. Migration Assistantを使ってバックアップからデータを復元
ストレージの選択:
- ユーザーデータのみをバックアップする場合、Mac本体と同程度の容量で十分
- 頻繁にアクセスする場合はSSD、コスト重視ならHDDを選択
- NASを使用すれば、ネットワーク経由で自動バックアップも可能

SuperDuperとTimeMachineの選択基準

私自身はSuperDuperを使用していますが、有償のソフトウェアですしApple謹製の TimeMachineを使いたい方もいると思います。次のような観点で選択すればよいと思います。

SuperDuperを選ぶ場合:
- バックアップから直接ファイルにアクセスしたい
- 標準ファイルシステムでの管理を好む
- 選択的なバックアップをしたい
- バックアップスケールや方法を自分で調整したい
TimeMachineを選ぶ場合:
- 設定の簡単さを重視
- 過去バージョンへの簡単なアクセスが必要
- macOSに標準搭載の機能のみで完結させたい

まとめ

Apple Silicon時代では、起動可能なバックアップよりも「確実にデータを保護し、必要時に復元できる」戦略が重要です。OSはリカバリーモードから再インストールし、大切なユーザーデータは確実にバックアップしておくことで、トラブル時も迅速に復旧できます。

SuperDuperの最新ベータ版ではブータビリティの改善が進んでいますが、現実的な運用としてはユーザーデータに焦点を当てた戦略が効率的です。

また、私はpCloudも使用しているため、特に重要なファイルはpCloud上で作業するようにしています。過去30日分のリビジョンが保存されますし、クラウドからいつでも取り出せます。

家庭用途では、特にストレージコストを考慮すると、データ中心の定期的バックアップとクラウドなどへの直近のデータの保管を併用すれば十分な保護が可能です。

ChromaLensCLI: Command Line Color Accessibility Validation

2025-01-25T00:00:00+00:00

とりあえず色覚異常の方にも画像が正しく認識できてるか確認するためのツール ChromaLens CLIを作ってみた。

ChromaLens CLIの使い方

使い方は、次の通り。

./chromalens input.jpg output.jpg --type tritanopia

これで色覚異常の方が実際どのようにインプットとなる画像が見えているかシミュレーションした画像が出力されます。 type オプションの指定は次の通りです。

protanopia (1型色覚)
deuteranopia (2型色覚)
tritanopia (3型色覚)

ChromeLens CLIの環境設定

以下は、venvでPythonの仮想環境を作って必要なパッケージをインストールする手順です。

python3 -m venv venv
source venv/bin/activate.fish
pip install numpy Pillow

以下が実際のコードです。chromalensというファイル名で保管ください。授業中に書いたコードなので、エラー処理などは省いています。

#!/usr/bin/env python3
from PIL import Image


class ColorVisionSimulator:
    MATRICES = {
        'protanopia': np.array([
            [0.567, 0.433, 0.000],
            [0.558, 0.442, 0.000],
            [0.000, 0.242, 0.758]
        ]),
        'deuteranopia': np.array([
            [0.625, 0.375, 0.000],
            [0.700, 0.300, 0.000],
            [0.000, 0.300, 0.700]
        ]),
        'tritanopia': np.array([
            [0.950, 0.050, 0.000],
            [0.000, 0.433, 0.567],
            [0.000, 0.475, 0.525]
        ])
    }


    def simulate(self, image_path, output_path, cvd_type):
        if cvd_type not in self.MATRICES:
            raise ValueError(f"Unsupported CVD type. Choose from: {', '.join(self.MATRICES.keys())}")


        # 画像を読み込み
        img = Image.open(image_path)
        # RGBAの場合はRGBに変換
        if img.mode == 'RGBA':
            img = img.convert('RGB')

        # NumPy配列に変換
        img_array = np.array(img)

        # 色変換行列を適用
        matrix = self.MATRICES[cvd_type]
        shape = img_array.shape
        pixels = img_array.reshape(-1, 3)
        converted = np.dot(pixels, matrix.T)

        # 値を0-255の範囲に収める
        converted = np.clip(converted, 0, 255)
        converted = converted.reshape(shape)

        # 画像として保存
        result = Image.fromarray(converted.astype('uint8'), 'RGB')
        result.save(output_path)


def main():
    parser = argparse.ArgumentParser(description='Color Vision Deficiency Simulator')
    parser.add_argument('input', help='Input image path')
    parser.add_argument('output', help='Output image path')
    parser.add_argument('--type', '-t', choices=['protanopia', 'deuteranopia', 'tritanopia'],
                        required=True, help='Type of color vision deficiency')

    args = parser.parse_args()

    simulator = ColorVisionSimulator()
    try:
        simulator.simulate(args.input, args.output, args.type)
        print(f"Simulation complete: {args.output}")
    except Exception as e:
        print(f"Error: {str(e)}")
        exit(1)


if __name__ == '__main__':
    main()

How to Merge and Optimize Your PDF Files

2025-01-10T00:00:00+00:00

Bypassing PDF Password Protection

While the DJI Neo user manual is provided in PDF format, it's password-protected, preventing any modifications or merging. Here's how to bypass the password protection on a Mac:

Open the PDF in the Preview app
Select "Print" from the File menu (note: not "Export")
Choose "Save as PDF" and specify the destination

This process will create a new PDF without password protection.

Merging PDFs

While this can be done with Ghostscript (mentioned later), we'll use pdftk for its advantages:

Preserves PDF internal structure (table of contents, bookmarks, links, etc.)
Operates at the binary level, preventing quality degradation
(Although not relevant for this case) Offers flexible operations like page rotation and reordering

Here's how to merge PDFs:

# Install pdftk (on Mac)
brew install pdftk-java


# Merge PDFs
pdftk input1.pdf input2.pdf cat output merged.pdf

PDF Optimization

After merging, I found that the file size exceeded 40MB, which was too large to upload to MLIT's DIPS2.0 (Drone/UAS Information Platform System).

To resolve this, I used Ghostscript for optimization:

# Install Ghostscript (on Mac)
brew install ghostscript


# Optimize PDF
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -dBATCH -sOutputFile=output.pdf input.pdf

The -dPDFSETTINGS option allows you to adjust the compression level:

/screen: For screen display (72dpi) - smallest file size
/ebook: For e-books (150dpi) - balanced compression
/printer: For printing (300dpi)
/prepress: For high-quality printing (highest quality)

Making PDF Searchable

Scanned PDFs aren't searchable. Use these Linux/Mac commands for OCR instead of expensive software:

brew install ocrmypdf
brew install tesseract-lang
# OCR with image optimization
ocrmypdf -l jpn --optimize 3 input.pdf output.pdf

Creating Table of contents

Scanned PDFs often lack a table of contents. Instead of buying expensive PDF software, use these Linux/Mac commands:

# Install pdftk (on Mac)
brew install pdftk-java
# Extract metadata
pdftk input.pdf dump_data_utf8 > metadata.txt

Open metadata.txt in your editor and add bookmark locations in this format:

BookmarkBegin
BookmarkTitle: Chapter 1
BookmarkLevel: 1
BookmarkPageNumber: 1
BookmarkBegin
BookmarkTitle: Chapter 2
BookmarkLevel: 1
BookmarkPageNumber: 10

Then apply the metadata to create a PDF with a table of contents:

# Apply edited metadata
pdftk input.pdf update_info_utf8 metadata.txt output output.pdf

Conclusion

With these steps, I successfully optimized the PDF and completed the drone registration.

However, it seems rather inefficient to require individual manual submissions for DJI drones, which are widely used. This feels like typical bureaucratic red tape.

Finally, while this may only be relevant for Japanese users, I'm sharing the prepared DJI Neo manual that meets DIPS2.0 requirements here: Download

A Failed Experiment: Using OpenCV to Read Printed Dates from Scanned Photos

2025-01-06T00:00:00+00:00

Organizing Old Photographs

I recently purchased a scanner at the end of the year to digitize old photographs. The photographs have dates printed on them, and I've been manually setting these dates in the EXIF information using ExifTool.

I use Hazel to organize image files, and I've already created a tool that updates file creation dates that Hazel can read with the shooting dates from EXIF data. However, since setting EXIF information manually is time-consuming, I explored the possibility of automating this process using OpenCV.

Date Reading Tool

Below is a script that uses OpenCV to read dates from images and set them using ExifTool.

#!/usr/bin/env python3
from datetime import datetime


def preprocess_image(image_path):
    """
    Extract and process the date stamp portion from the image
    """
    # Load image
    img = cv2.imread(image_path)
    height, width = img.shape[:2]

    # Crop the bottom right region
    x1 = int(width * 0.65)
    y1 = int(height * 0.75)
    cropped = img[y1:height, x1:width]

    # Split channels
    b, g, r = cv2.split(cropped)

    # Enhance red channel
    red_emphasis = cv2.subtract(r, cv2.max(b, g))

    # Enhance contrast using CLAHE
    clahe = cv2.createCLAHE(clipLimit=3.0, tileGridSize=(8,8))
    enhanced = clahe.apply(red_emphasis)

    # Strong thresholding
    _, binary = cv2.threshold(enhanced, 30, 255, cv2.THRESH_BINARY)

    # Remove noise
    kernel = np.ones((2,2), np.uint8)
    cleaned = cv2.morphologyEx(binary, cv2.MORPH_OPEN, kernel)

    # Detect and filter contours
    contours, _ = cv2.findContours(cleaned, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE)

    # Filter by area
    mask = np.zeros_like(cleaned)
    min_area = 10
    max_area = 500

    for contour in contours:
        area = cv2.contourArea(contour)
        if min_area < area < max_area:
            cv2.drawContours(mask, [contour], -1, (255), -1)

    # Resize to 4x
    result = cv2.resize(mask, None, fx=4, fy=4, interpolation=cv2.INTER_CUBIC)

    # Save debug images
    debug_dir = os.path.join(os.path.dirname(image_path), 'debug')
    os.makedirs(debug_dir, exist_ok=True)

    basename = os.path.basename(image_path)
    cv2.imwrite(os.path.join(debug_dir, f'cropped_{basename}'), cropped)
    cv2.imwrite(os.path.join(debug_dir, f'red_emphasis_{basename}'), red_emphasis)
    cv2.imwrite(os.path.join(debug_dir, f'enhanced_{basename}'), enhanced)
    cv2.imwrite(os.path.join(debug_dir, f'binary_{basename}'), binary)
    cv2.imwrite(os.path.join(debug_dir, f'result_{basename}'), result)

    return result


def extract_date_from_image(image_path):
    """Extract date from image using OCR"""
    # Preprocess image
    processed_image = preprocess_image(image_path)

    # OCR configuration for single line text
    custom_configs = [
        '--psm 6 -c tessedit_char_whitelist="0123456789\' "',  # Uniform text block
        '--psm 7 -c tessedit_char_whitelist="0123456789\' "',  # Single text line
        '--psm 8 -c tessedit_char_whitelist="0123456789\' "',  # Single word
        '--psm 10 -c tessedit_char_whitelist="0123456789\' "'  # Single character
    ]

    for config in custom_configs:
        # Run OCR
        text = pytesseract.image_to_string(processed_image, config=config)
        text = text.strip()
        print(f"OCR result (config={config}): [{text}]")

        # Normalize spaces
        text = ' '.join(text.split())

        # Simple pattern matching
        pattern = r"'?(\d{2})\s*(\d{1,2})\s*(\d{1,2})"
        match = re.search(pattern, text)

        if match:
            try:
                year = int(match.group(1))
                month = int(match.group(2))
                day = int(match.group(3))

                # Handle 2000s
                year = 2000 + year if year < 50 else 1900 + year

                if 1 <= month <= 12 and 1 <= day <= 31:
                    return datetime(year, month, day)
            except ValueError:
                continue

    return None


def set_exif_date(image_path, date):
    """Set EXIF date information using ExifTool"""
    if not date:
        print(f"No date found in: {image_path}")
        return False

    date_str = date.strftime("%Y:%m:%d")

    # EXIF tags to set
    exif_tags = [
        "DateTimeOriginal",
        "CreateDate",
        "ModifyDate"
    ]

    command = ["exiftool", "-overwrite_original_in_place"]
    for tag in exif_tags:
        command.extend([f"-{tag}={date_str}"])
    command.append(image_path)

    try:
        subprocess.run(command, check=True, capture_output=True)
        print(f"Date set successfully: {image_path} -> {date_str}")
        return True
    except subprocess.CalledProcessError as e:
        print(f"Failed to set EXIF information: {e}")
        return False


def process_images(directory):
    """Process all images in the specified directory"""
    processed = 0
    failed = 0

    for filename in os.listdir(directory):
        if filename.lower().endswith(('.png', '.jpg', '.jpeg')):
            image_path = os.path.join(directory, filename)
            date = extract_date_from_image(image_path)

            if set_exif_date(image_path, date):
                processed += 1
            else:
                failed += 1

    print(f"\nProcessing complete:")
    print(f"Success: {processed}")
    print(f"Failed: {failed}")


def main():
    if len(sys.argv) != 2:
        print("Usage: photodate <image_directory>")
        sys.exit(1)

    directory = sys.argv[1]
    if not os.path.isdir(directory):
        print("Specified path is not a valid directory")
        sys.exit(1)

    process_images(directory)


if __name__ == "__main__":
    main()

Results

I tested the script on 27 scanned photographs.

Out of 27 images, the script only detected dates in 4 images, and among those, only 1 date was correctly recognized.

Well, this isn't practical enough to use.

A Command to Sync EXIF Data with File System Timestamps

2024-12-30T00:00:00+00:00

The scanner's performance has been impressive - it handled even my old San Francisco business trip photos from 2001 beautifully, producing crisp, clear scans.

Setting EXIF Information

Unlike photos taken with a digital camera, scanned images don't come with proper EXIF data. To preserve the actual capture dates of these photos, I used exiftool from the command line to set the correct EXIF information:

# Example: Setting the original capture date
exiftool "-DateTimeOriginal=2001:04:15 10:00:00" photo.jpg

This command successfully embeds the correct capture date in the photo's EXIF data.

The Photo Organization

For managing my photo files, I rely on Hazel, a powerful file organization tool for Mac. Hazel offers some fantastic automation features:

Filtering based on file creation and modification dates
Automatic folder organization
Smart file renaming

However, Hazel has one limitation that's been bugging me: it can't directly read EXIF data. This means that even though I've carefully added the correct capture dates to the EXIF data, I can't use this information for Hazel's automated organization.

The Solution: adj-photodate Script

To bridge this gap, I created a script that syncs EXIF information with the file system timestamps (creation and modification dates). This enables Hazel to organize photos based on their actual capture dates.

The script provides the following features:

Syncs DateTimeOriginal from EXIF to file system timestamps
Includes a dry-run mode for previewing changes
Handles batch processing of multiple files
Supports recursive directory processing

Installation

Create a file named "adj-photodate" and paste the following script:
- adj-photodate
Make it executable:
```
chmod +x adj-photodate
```
Optionally, move it to your path:
```
cp adj-photodate ~/bin/
```
Dependencies:

bash shell
exiftool

Usage

# Process a single file
./adj-photodate photo.jpg

# Preview changes with dry-run
./adj-photodate -n photo.jpg

# Process all JPEG files in a directory recursively
./adj-photodate -r ~/Pictures/Scanned

To see available options:

./adj-photodate --help

コマンドラインで画像のExif修正

2024-08-23T00:00:00+00:00

デジカメの日付の設定を間違えExifの日付を修正したかったが、 AppStoreから余計なアプリをインストールしたくなかったので、Homebrewでexiftoolをインストールして修正。

# Install exiftool using Homebrew
brew install exiftool

# Confirm dates of exif
exiftool R0000001.jpg
    ExifTool Version Number         : 12.76
    File Name                       : R0000001.JPG
    Directory                       : .
    File Size                       : 12 MB
    File Modification Date/Time     : 2024:08:26 12:42:29+09:00
    File Access Date/Time           : 2024:08:26 12:43:26+09:00
    File Inode Change Date/Time     : 2024:08:26 12:43:24+09:00
    File Permissions                : -rwx------
    File Type                       : JPEG
    File Type Extension             : jpg
    MIME Type                       : image/jpeg
    Exif Byte Order                 : Little-endian (Intel, II)
    (Output truncated for brevity)

# Modify dates of exif
exiftool -Alldates='2024:08:23 12:11:00' -overwrite_original ./*