伝説のMagic Lanternが復活！Canonカメラ使いは要チェック？
引用元：https://news.ycombinator.com/item?id=45078315
Magic Lanternを知らない人のために説明するね。Magic LanternはCanon EOSカメラにSD/CFカードから動くフリーのソフトアドオンで、Canonが工場出荷時には搭載しなかった新機能をたくさん追加できるんだ。サポート対象外になった古いCanonカメラにも新機能を移植するし、リバースエンジニアリングと古いハードウェアを役立たせる点で本当にすごい成果だよ。
補足情報だよ。デジカメの現代世代より前は、Magic Lanternは初期のCanonカメラからRAWビデオ録画含む多くのパワーを引き出す初期の方法の一つだったんだ。今はBlackmagicみたいなカメラやDaVinciのような編集プラットフォームがRAWをシームレスに扱うけど、数年前はこうじゃなかったんだよ。
面白いね、.fm TLDを使ってるのを見て、なんかオンラインラジオかと思ったよ。
当時はそれがトレンドだったんだよ :D
もしかしたら誰かがファームウェアにちょっと似てると思ったのかもね？
僕もだよ :) soma.fmのGroove Saladを思い出したよ。
Fujifilmみたいな他のカメラブランドにも似たプロジェクトがあればいいのにって思うよ。古いCanonカメラでのMagic Lanternの機能を見れば、他のブランドの古い機械にもたくさんの可能性があるってわかるよね。これは「eco」フレンドリーなアプローチだし、サポートされるべきだよ。
Canonがカメラのクリーンな動画出力に月額5ドルを課し始めたから、enshitificationでFujifilmに乗り換えたよ。メーカーがカメラをサブスクにするなんて、俺たちマジで困るわ。
Fujiはいいんだけど、エコシステムが小さいのが難点だね。X-transのデベイヤー処理に対応してないソフトもまだあるんだよな。
うん、Adobeとかね。あそこのやり方は10年以上もずっとピークのワーム作成だよ。Capture Oneやdcrawの方がはるかにマシだね。
スクリプトシステムもあるし、いじるのがマジで楽しいんだよな。
このニッチだけどクールなプロジェクトに感謝！俺が現在のリード開発者だから、なんでも質問してね。CanonのDSLRやミラーレスを持ってて、ソフトのリバースエンジニアリングに興味あるなら参加を検討してみてよ。100ドル以下でサポートされてるカメラが手に入るし、ARMv5teからAArch64まで対応してるよ。
最近、astro改造済みの6Dを手に入れたんだ。昔ティーンエイジャーの頃にCHDKは使ってたけど、Magic Lanternは初めてなんだよね。コンパイラ開発者で低レベルスキルもあるんだけど、プロジェクトのために何か見るべきことや、俺の‘新しい’6Dで試すべきことある？R62はまだいじりたくないんだ。
俺の1Ds3にも入れたいな。昔、Canonが1Dには手を出すなってML開発者に強く警告したって読んだ気がするけど、もうあんな古いカメラなら大丈夫でしょ。(RAWヒストグラムだけ欲しいんだよね)(1Dx2も持ってるけど、そっちは多分もっと移植が難しいだろうな)
astro改造いいよね！面白いアイデアがあるんだ。カメラ自体をスター・トラッカーにして、シリアルでマウントを制御しながら撮影できるんじゃないかな。6Dはよく分かってるカメラだし、君のコンパイラのバックグラウンドはかなり役立つよ。6DのWifiも理解されてるから、自動画像アップロードサービスとかどう？imgurとかOAuthと連携できたらクールだね。作業は遅いけど、コンパイラ開発もそんなもんだろ？
スター・トラッカーってのは「オートガイダー」って言うのがいいかもね。メインカメラでできたら超便利だよね。ノイズは増えるかもしれないけど、その便利さの方が価値あると思うな。信号もシンプルだし、いつか試してみるよ。自動画像アップロードも超便利そう！俺も6DにML入れてネットワークスタック試してみるよ。誰かやりたいけど手が回ってない要望リストとかある？
CanonはMLプロジェクトと今まで一切関わりがないと俺は思うな。1Dシリーズから距離を置くって決めたのはMLチーム側で、Canonを刺激しないようにすごく気を使った結果だと思うよ。
俺はいまだにMLファームウェアのおかげで5Dmkiiを使ってるよ。今は主にタイムラプスカメラとしてだけど、ETTR機能が最高に気に入ってるんだ。一番の難点は5秒未満のインターバルだとMLソフトが混乱して不規則になっちゃうこと。5秒以上ならバッチリだよ。ほとんどの撮影で外部タイマーはいらないね。5秒未満の時は外部タイマーを使ってるけど。シャッターが壊れるのを待ってるんだけど、きっと修理してこのボディとMLを使い続けると思う。開発を続けてくれてありがとう、そして以前関わった人たちにも感謝！
最近、実際のハードウェアで動かす状況ってどうなってるの？5年前、4000Dでエミュレータじゃなく、実際にカメラでコードを動かそうとしたら、a1exにキーか何かがいるって言われたんだ。サインしてくれるって言われたけど、忙しくなってそれっきりなんだよね。この状況って今も同じなのかな？（うろ覚えでごめんね。5年前の話だからさ！）
俺は確かに天体撮影初心者なんだ :) LVサンプリングは最初に思いついたアイデアだよ。次の画像を撮ってる間に前の画像をロードして、そこからガイドポイントを抽出することもできるよ（個別のフレームに十分な明るいポイントがあればだけど…ないかもしれないし、ソフトウェアで数枚合成してもいい）。画像は大きいけど、時間的な制約は厳しくないはず。そうすれば余計なセンサー熱は出ない。CPU熱は多少出るけど、気づくほどじゃないかな。
ネットワーキングについては、このモジュールが原理を示してるよ: https://github.com/reticulatedpines/magiclantern_simplified/…
カメラから画像データを受け取って、処理をしてデータを送り返す、シンプルなPythonサーバーさ。ネットワークプロトコルは超簡単。ネットワーク認証情報やIPアドレスなんかを保持する設定ファイルのフォーマットは、正直かなりひどいね。コードを書く都合で作ったから、設定ファイルを作る都合じゃなかったんだ。
同等のネットワーキング機能（俺たちの専門用語では「stubs」）を見つける必要があるよ。GhidraやIDA Proに詳しかったり、6Dと200DのROMダンプを持ってたりしない限り、これには助けが必要になるだろうね :) その段階になったらDiscordに来てくれ。ここでは詳しすぎるからさ。
みんなが何を欲しがってるかのリストは特にないよ（まあ、みんな全部欲しがってるんだけど…）。repoのissueを見れば良いアイデアがいくつかあるはず。初期の頃は「Good First Issue」ってタグをいくつか付けたけど、結局一人でやってたから諦めちゃったんだ。
個人的にモチベーションを感じるものを見つけるのがもっと重要だと思うよ。その方が続けられる可能性が高いからね。慣れればずっと楽になるけど、優しい学習曲線じゃないからさ。
120秒の露光中にLVサンプリングって動くの？
見直す時期かもしれないね。Canonは今後フラッグシップのDSLRを計画してないらしいし、自分の持ち物を改造するのに何も悪いことはないと思うよ。
それはさておき、ML開発ってカメラ自体にとってどれくらい危険なの？（ブリックさせる可能性は？）1DXくらいの値段のカメラを完全にダメにするのは、俺にとって楽しい時間じゃないね。:-)
おかしいな、一部のボディでは5秒未満でも確実にできるんだけど。でも、俺は5d2を持ってないからテストできないんだ。
これは長時間露光との競合かな？AFも考えられるね。インターバルタイマーは5秒ごとにキャプチャをトリガーしようとするんだけど、AFでピント合わせ、露光、カードへの保存（など）の合計時間が5秒を超えると、1ショット飛ばされちゃうよ。
その時が来たら、中古の5d3の値段と5d2のシャッター交換の値段を比較してみて。もしかしたら「無料」でアップグレードできるかもね :) 優しい言葉をありがとう！
「ありがとう」って言いたいな。Canon 5D Mark III（5d3）でMagic Lanternを使ってるんだけど、本当に最高のソフトだよ。趣味の自然写真家として、これで信じられないような瞬間をたくさん撮れたんだ。Canon R7も持ってるけど、やっぱりDSLRのOVFの感覚が好きだし、Canon EFレンズも気に入ってるから、5d3が一番のお気に入り。プログラマーの友達にデモすると、みんな感動するよ。見てみてね: https://amontalenti.com/photos
それは数年前の話だったに違いないね。「カメラブートフラグ」を有効にする話だと思うよ。リリースビルドの新規インストールでは自動でできるようにしてるけど、安定版ができるまでは簡単にはしすぎないようにしてるんだ。みんな変なことをするからね。違うカメラ用のファームウェアをフラッシュして、その違うカメラ用のMLビルドを動かそうとしたりするんだよ…。
まあ、やり方は喜んで説明するよ。Discordが一番簡単かな、それかフォーラムで聞いてもいいよ。Discordはフォーラムからリンクされてる: https://www.magiclantern.fm/forum/
当時のコードは、いくつか更新しないとビルドできないと思う。4000DはMLにとって良いターゲットだよ、たくさんの機能が追加できるはずだ。
うわー、新しくサポートされるモデルがあるなんて、めちゃくちゃ興奮するね！俺はMLをいじるために5d mk iiiを買ったんだ。ビデオ撮影はあまりやったことないけど、少なくともmk iiiでb-rollを撮ったり、友達のライブイベントを記録したりするつもりだよ。
＞ 僕は現在のリードデベロッパーだから、質問してね。
って言われたら聞くしかないじゃん！
このプロジェクトについていつも疑問に思ってたことなんだけど、サポートできるモデルとできないモデルの違いって何？MLの将来の互換性に「これは絶対無理！」っていう壁があるの？それとも、ハードウェアとかファームウェアの何かを見て「おっ、これは有望だ！次これいけるんじゃないか？」ってなるモデルってあるの？
あと、外部の人間として、100ドルくらい出してMLをいじるのが自分に向いてるか試したいんだけど、開発環境として一番簡単な（安い）モデルってどれかな？（または、誰かが機能開発するためにやるような構成で）あと、そのやり方のドキュメントはどこにある？リバースエンジニアリングの観点から、これらのカメラがどう動くかの知識をまとめたものってあるの？それとも、みんなフォーラムの投稿とかCanonの公式技術ドキュメントで苦労して学ぶ感じ？
追記: ウェブサイトのREガイド見つけたよ、今夜見てみるね
ライブビュー中に撮影画像は表示できないんだ。センサーからの読み出しと撮影は別プロセスだからね。でも、短い露光と長い露光を交互に撮って、短い方だけライブビューに出すって手はあるかも。ドリフトは正確に予測できるし、保存した画像で調整できるからライブビューは必ずしもいらないよ。書き出し前のメモリ内画像で色々できるんだ。
MLが君の役に立ったなら嬉しいな。もっとプログラマーを仲間に引き込んでよ！R7は開発ターゲットだけど、まだ誰も着手してないんだ。R5とR6は初期段階の作業が進んでるよ。R7は新世代のクアッドコアAArch64かもね。最近のカメラはパワフルだから、YOLOをカメラ内で動かして、サブ1秒で何か面白いことができるんじゃないかな。
長秒露光のせいかな？1/2秒露光と3秒インターバルでたくさん撮ったら、3秒より短いのも長いのも出たんだ。ドキュメントに5秒が壁ってあったけど、5dmkiiだけかも。俺のカードは速いから書き込み速度が原因じゃないと思う。安い外部タイマーだと問題ないし、カメラのせいじゃないんじゃないかな。
これまで開発中に一時的にカメラが壊れちゃった人が何人かいたけど、みんな直ったよ！物理的な損傷はなかったはず。もちろんリスクはあるけど、OSの仕組みを利用して慎重に進めてるから大丈夫。でも、高価なカメラでいきなり挑戦するのはおすすめしないかな。まずは安いカメラで練習するのがいいと思う。
もっとコメントを表示（1）
2020年9月のことだね。ROM dumperは動いたし、QEMUでファームウェアも起動できたよ。あとはたくさんの機能ポインタを見つけるだけだったんだけど、ハードウェアで動かす方法がなくて、そこで挫折したんだ。また時間ができたら、ぜひ連絡するね。
このプロジェクトに本当に感謝してるよ！600Dで短編映画、ミュージックビデオ、TVパイロットまで、たくさん撮影できたんだ。MLのおかげで、このカメラが長く使えるようになったし、本当に素晴らしいことだよ！
僕もずっとMagic Lanternの開発に加わりたいって思ってたんだ（Discordにはいるよ）。でも、なかなか時間が取れなくてね。改めて、本当にありがとう！
ドリフトを時間経過とともに正確にモデル化するんだね。それなら、きっと誰かがソフトウェアを作ったはずだ！
外部タイマーの件は有力な証拠だね。気になるのは、カメラにはミリ秒・マイクロ秒単位のHWクロックがあって、スケジューリングやスリープもできるはずなのに、変な癖があるってこと。5D2の内部は詳しくないけど、画像キャプチャはRTOSでスリープや遅延を避けるように作られてるみたい。もしデバッグしたいなら、Discordに来てくれたらテストを作ってあげるよ。
古い1Dを試そうかなって思ってたんだ。誰かが1DをPLマウントに改造してたのを見たことがあるよ。ボディが厚いからフランジバックが合ったみたい。35,000ドルの17mmレンズを付けてて、俺の機材だと何秒もかかる夜空の撮影が1/3秒でできてたんだ。ボートの先にカメラをつけて、ナイトビジョンゴーグルで川を下って撮った写真、すごく良かったんだ。いつもそんなクレイジーなことやってみたいって思ってるよ。
このプロジェクトを続けてくれて本当にありがとう！2014年にMagic Lanternを使ってCanonカメラで4K動画撮影をアンロックできたんだ。当時は高価な機材がなくても、学生がプロみたいな動画を撮り始められる唯一の方法だったよ。
5D3は動画に最適なML対応カメラかもね。CFとSDカードを同時に使えば約145MB/sで記録できて、すごく高画質な映像が撮れるんだ。MLはリバースエンジニアリングプロジェクトだから、時間さえあれば何でもサポートできるよ。
開発者がサポートするカメラは、俺が安く手に入れたり、他の開発者が優先するカメラ次第で、かなりランダム。 docsは今、複数のWikiやフォーラム、リポジトリのコミットメッセージに散らばってるから、Discordが開発の質問には一番良い場所だね。俺はDev Guideも作ってるけど、まだ完全じゃないよ：https://github.com/reticulatedpines/magiclantern_simplified/…
物理的なハードウェアで遊びたいなら、650Dか700Dを100ドルくらいで見つけられるかもね。Digic 5のカメラがおすすめです：https://en.wikipedia.org/wiki/Template:Canon_EOS_digital_cam…
それはa1exが去る少し前の話だね。コードを実機で動かすのは簡単だよ。数ヶ月後に君が探し求めている”自由な時間”を見つけたら、Discordで話そうか ;)
4000Dは面白いカメラで、ポートを始めた人が何人かいたけど、途中で諦めてる。古いCPU/ASICを使っててハードウェアは2008年のものなのに、OSは最近のビルドに更新されてるんだ。これがMLコードが期待するものではないから、俺たちの前提が混乱させられてるんだよね。でも、4000Dは比較的簡単にポートできるはずだよ。
1Ds3は今でも素晴らしい画像を生成するけど、UIが今はすごく制限されているように感じるな。MLがあれば劇的に変わるだろうね。
俺はCanon 650DでMagic Lanternを使って、Blackmagic ATEMにクリーンフィードを送ってるよ。インストールは簡単だったし、すべてうまく動いてる！
Magic Lanternチーム、ありがとう！
「必要なのはCの知識だけ。これは良いチュートリアルがある小さな言語だ」って言うのは、「必要なのはバイオリンを弾けることだけ。これは良いチュートリアルがある小さな楽器だ」って言うのとちょっと似てるね。
俺は自分の発言を撤回しないよ！C言語の規格の長さをJS/ECMAScriptやC++と比べてみてくれ！:)
多分、複雑さ対組み込み機能のトレードオフを隠してるのかもしれないけど、ボランティアは後で自分で解決できるさ。一部の分野ではCの知識はそんなに必要ないよ。ML GUIはルールを守れば簡単に修正できるんだ。他の分野、例えば複雑な機能を新しいカメラに移植するのはずっと難しいけどね。それがリバースエンジニアの宿命さ。
君の言うことには一部同意するけど、C規格の簡潔さは、フットガンや未定義動作が多いってことでもあるよね。Cは色々なものだけど、簡単に習得できる言語じゃない。大学を卒業するまではCが大好きだったけど、最近はプロジェクトでCを使うのはかなり抵抗があるな。俺にとってCを扱うのはアセンブリを扱うのに似てて、「本当のプログラミングをしてる」って感じるけど、現実的にはほとんどのシナリオで今はもっと良い選択肢があるよ。
君の言うことには一部同意するよ。Cで作業する際のよく知られたリスクの一部は、規格が小さいからなんだ。でも、未定義動作の多くは当時のハードウェアをサポートするために意図的にそうなってるんだよ。低レベル言語として異なるアーキテクチャ間でクロスプラットフォームにするのは難しいからね。
Cは本当に習得しやすい言語だよ。マスターするのは難しいけどね。そして君の言う通り、多くのドメインでは今、もっと良い選択肢があるから、マスターする価値はないかもしれないね。
古い言語だから、組み込みの安全機能が欠けている分、何十年にもわたる非常に優れた周辺ツールがそれを補ってくれるんだ。もちろん、そのツールも学ぶ必要があるし、使うことを選択する必要もあるけどね！
Magic Lanternの文脈では、Cが自然にフィットするんだ。OSによる非常に厳しいメモリ制限の中で作業しているからね。俺たちはシングルコア200Mhzターゲット（ARMv5、アウトオブオーダーや他の派手なトリックなし）をサポートしてる。C標準ライブラリは含んでいないから、小さなテストバイナリは1kB未満になることもある。通常のビルドは約400kBだよ（これには完全なGUI、デバッグ機能、すべての文字列とアセットなどが含まれる）。
CanonのコードはおそらくほとんどがCで、一部はC++なんだ。俺たちは彼らのコードを直接呼び出す必要がある（基本的にリバースエンジニアリングしたアドレスを関数ポインタにキャストしてね）。彼らのコードがどのような安全保証をしているか、APIがどうなっているかはわからないんだ。俺たちの作業のほとんどはOSやハードウェアとのやり取りだから、俺たちの側で安全な言語を使っても、あまりメリットはないんだよ。
「Cは簡単に習得できる」って意見は、XKCD 2501みたいな状況だよね。HNに投稿するような経験豊富な人たちにとってCは簡単でも、JavaScriptやPythonしか知らない学生は「参照渡し」すら分からず、Cを簡単だとは思わないはず。
https://xkcd.com/2501/
プログラミング未経験者に教えてきたけど、Cの基礎はJavaやC++より教えやすいね。初心者を混乱させる要素や、自分でコードをぶっ壊せる点は確かにあるけど、それは後で出てくる話。
「Cを極めるのが簡単」とは言ってないけど、「始めるのが簡単」ってことだよ。
アセンブリ（自分は6502だけど、どれでも同じかな）をやってからCを触ったら、すごく分かりやすくなったよ。「参照渡し」みたいなことも、なるほどって納得できたんだ。
同感。自分も初心者だった頃、Cの基礎は比較的簡単に学べたよ。全ての詳細をマスターして熟練者になったわけじゃないけど、基本的な概念はそんなに難しくなかったし、理解すべきことが多すぎるってこともないもんね。
ハーバードのMOOC、CS50xではCがプログラミングの導入として教えられてるよ。
clangはgccより良いエラーメッセージを出すし、AIやLLM、copilotツールもCには強いだろうね。
K&R CとLinuxシェルしかなかった昔に比べて、今はCを始めるのが少し簡単になってるよ。
CS50xはすごく質の高いコースだからおすすめ。
https://news.ycombinator.com/item?id=40690760
Pythonでは全部「参照渡し」で、Cでは全部「値渡し」だよ。
Pythonについては、完全に正しいってわけじゃないけど、かなり近い近似値だね。
どこの学校に行ったかによるんじゃない？
僕が通った学校では、2010年代はCとLISPから始まって、その後C++とJava、Pythonに進んだよ。
未定義動作は確かにあるけど、それ自体が即座に大問題になるわけじゃないよ。
良いコード例から始めれば、そんなに遭遇しないしね。
サポートされる機能の説明と「未サポートなことは壊れるかもよ」っていう警告の方が大事なんだ。
すべてを予測可能にするやり方は、逆に複雑な仕様と、設計・論理的にマズいコードを生みがちだからね。
やっぱり自分の意見は変わらないな！
バイオリンの弦の数をピアノの鍵盤の数と比べてみなよ！ :)
ピアノは鍵盤がハッキリしてるし順序立ててるから、ほぼ間違いなく一番学びやすい楽器だよな。
それが本題だろ。仕様が短いからって言語が学びやすいわけじゃないし、弦が少ないからって楽器が弾きやすいわけじゃないってこと。
その例えは全然違う。仕様が小さい言語はもっと学びやすいって。素晴らしい仕事をしてきた開発者が、C言語を「けだもの」から守るのに時間使うとか悲しいわ。Cはもう変わらないんだし。
反対する人を荒らし呼ばわりしても、お前の主張は強くならないぞ。
家具の道具に文句言う奴なんていないだろ。これじゃあまるで宗教論争じゃん。
もっとコメントを表示（2）
＞仕様が小さい言語は学びやすい。
それは他の条件が全部同じならの話だろ？でも、そんなことって絶対ないんだよな。
＞今はGit使って、モダンなOSとツールで警告なしにビルドしてるって話だろ。大変だったけど、開発者には超便利になったらしい。すごいな！地味だけど報われない作業だ。俺も自分のプロジェクトの警告見直さないと…。
最初から習慣にすれば難しくないよ。俺は全プロジェクトにxcconfigファイル[0]入れてて、警告をエラー扱いにして、全警告オンにしてる。C言語だと-wallだね。SwiftLint[1]も使ってる。良い習慣がついたから、最近はほとんど警告出ないよ。Magic Lanternがファームウェアなのに、これができてなかったのが驚き。ファームウェアって完璧に近いべきだろ（昔書いてたから品質にはめっちゃうるさいんだ）。
[0] https://github.com/RiftValleySoftware/RVS_Checkbox/blob/main/RVS_Checkbox.xcconfig
[1] https://littlegreenviper.com/swiftlint/
ファームウェアじゃないよ :) カメラのOSの機能を使って、ディスクからファイルを読み込んで実行してるんだ。（ほぼ）普通のプログラムとして動いてる。ビルドオプションは-Wallとか色々使ってるよ。リリースビルドでは警告をエラーとして扱ってるし。
ありがとう。ダウンボートはしてないよ（アカウントが新しすぎてできないんだ笑）。最初からやればコンパイラ警告を避けるのは難しくないし、一つずつ直せばいい。でも、ドキュメントのないハードウェア向けに何十年も前のコードで警告を全部直すのはマジで大変。しかもgcc 5から12にツールチェインをアップデートしたばかりだしね。
ダウンボートは気にしないで。ソフトウェアの品質改善の話をするといつもこうなるんだよ。Canonの競合他社で働いてたんだけど、Magic Lanternみたいなことをしたかったのに、彼らはクソ頑固でね。個人的にはデバイス上で動くソフトは全部ファームウェアだと思ってて、OSと同じ基準で見るべきだと思ってる。Magic Lanternは昔から良いって評判だったし、REDも似たようなの出してたよね。今どうなってるんだろう？
MLが知られてるのは嬉しいね！俺もQAとC言語のコードのセキュリティテストを経験してるから品質はめちゃくちゃ大事。ValgrindやASANをRTOSで動かすのは大変だけど、Qemuなら現実的かもね。ファームウェアとソフトウェアの区別だけど、みんながファームウェアって聞くとスマホのROM書き換えみたいにリスクが高いと思って、Canonのメニューが消えるとか勘違いするんだ。でもMLはそうじゃないから、区別してるんだよ。
良い点だね、結局は言葉の問題。俺の基準だとネイティブなモバイルアプリも“ファームウェア”って言えるかも。モバイルアプリにも昔のファームウェアプロジェクトと同じくらい力を入れてるよ。初めて出荷したエンジニアリングプロジェクトで品質にはめちゃくちゃ慎重になったんだ。動く部分に影響するソフトウェアはすごくよくテストしないとダメだね。ファームウェアは大丈夫だったけど、ドライバは高価なものを壊したこともあるし。
URL: https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
そうだね、ソリッドステートストレージが速いと境界が曖昧になる。IoTでファームウェア開発者は増えたけど、品質はイマイチだね。Magic Lanternが何に分類されても、ハードウェアを壊す可能性はある。特にシャッターは脆弱で、Canonは電源オフ時に大事なROMに設定を書き込むから、それが不整合だと起動しなくなることも。だからリリースするものはしっかり対策してるよ。個人的なテストでバカなことして、一度だけUARTアクセスで復旧したけどね。JTAGピン配置を見つける突破口があったから、ICEみたいなこともできるようになるかも。
シャッターは気をつけないとね。損傷したり、ゴミがついたりする可能性があるから。うちもシャッターでセンサーにゴミが付くから、ソフトウェアでダスト除去を追加しないといけなかったんだ。いつかセンサー技術が進歩して、メカシャッターが不要になる日が来ることを願ってるよ。
素晴らしいね、リンクありがとう。ところで、Rift Valley Softwareって？俺はケニアから書いてるんだ。そこはGreat Rift Valleyがある場所の一つだよ。ナイロビの北にある急斜面を車で降りるのは本当にすごい体験だよ！
俺、昔ウガンダに住んでたんだ。ウガンダ南西部のRift Valleyに行ったのは、子供の頃の最高の思い出の一つだよ。もう一つの会社、Little Green Viperもそれをもじってるんだ。アフリカ生まれで、最初の11年間はそこで過ごしたよ。でも1973年に急いでウガンダを離れなきゃいけなかったんだけどね。
そう！写真業界のソフト開発者として、こういうプロジェクトは本当に必要だよ。写真の世界は独自規格のソフトウェアやフォーマット、ロックされたハードウェアだらけでさ。デジタルカメラはただのコンピューターなのに、スマホ時代に慣れちゃうと、カメラのオンボードソフトウェアがどれだけ制限されてて時代遅れかってのが痛いほど分かる。音楽制作と比較すると、そっちはもっとオープンなソフトウェアやハードウェアの取り組みがあって、大企業に縛られない自由があるんだ。Magic Lantern、万歳！
わかるわー。.x3fファイルとSigma Photo Proで泣いてるよ。
もしmacOSユーザーで知らなかったら、これ気に入るかもよ → https://x3fuse.com/
残念ながらGitHubオーガニゼーションを使ってないから、もしアカウントが消えたらまた失敗しちゃうよ。継続って難しいよね。＞ git clone https://github.com/reticulatedpines/magiclantern_simplified
コードがあるのに、どうして失敗するって言うの？
もしgithub.com/magiclantern/magiclanternみたいにGitHubオーガニゼーションを使っていれば、組織ユーザーの変更で所有権を移せるんだよ。
Magic Lanternの代替にはCHDKがあるけど、それもちょっと放置気味で、かろうじて動いてる感じなんだよね。だからMLが復活してくれて嬉しいよ。ニッチで複雑なリバースエンジニアリングプロジェクトの維持は本当に大変なことだよ。
https://chdk.fandom.com/wiki/CHDK
これは良いニュースだね。僕もいつかやりたいと思ってたけど、ずっと後回しになってたプロジェクトなんだ。5年間も休止してたなんて驚きだね。クールなフリーウェアの、あまり知られてない大変な一面って感じだね。
https://www.newsshooter.com/2025/06/21/the-genie-is-out-of-t…
今が始めるチャンスだよ！開発インフラを現代のプラットフォームとツールに対応させたから、前より簡単に始められるよ。Ghidraも登場して、すごく助けになったんだ。休止してたわけじゃなくて、前のリード開発者が辞めてターゲットハードウェアが変わったから一時的に減速したんだ。今は通常の速度に戻ったけど、まだ開発者が必要で、今は3人いるよ。
古いEOSでMagic Lanternがどれだけすごいか見たければ、Discordを見てみて。この小さなカメラがここまで性能を引き出せるのは驚きだよ。これは本当に楽しい趣味のプロジェクトだね。僕は時間がなくなってSony APS-Cとvintage lensesに移ったけど、それでもこの美しさは保てたし、ビデオのカクつきにイライラすることもなくなったよ。でもやっぱり、本当にクールなプロジェクトだね。
このニュースは、たぶん僕が4台目のEOSを買う言い訳になるね。最初の3台は100%Magic Lanternが理由だったから。メーカーがこれを難しくする理由が理解できないよ。だって、ハードウェアが売れるのにね。
