日記・コラム・つぶやき 映画「ストリートファイター/ザ・ムービー」を観てきました。
上映終了してなくてよかったー。
ええ、結構面白かったですよ。
0
PC関係 onedriveのなんかがダメになったぽいので、copilot継続は無理かもしんない。
copilotも、限定範囲の資料だけをベースに回答する、ノートブック機能があるんですが、これ、資料がonedriveに入ってるようでして。
ゲーム案考えてたり、ピンボケ写真の選別とか、色々と資料をノートブックに入れてたんですが、copilotがその資料を見えないとか言い出しまして。
で、色々やってみたところ、どうもonedriveそのものに問題がありそう。
元々、onedriveには良い印象無くてPCと同期はしてない、基本使わない、てことで、copilotでの使用もcopilotから見える範囲か、ブラウザ版onedriveからの操作だけ、てことでやってたんですよ。
したら、昨日の晩あたりから「この資料（チャット欄横のノートブックに表示されてるファイル）を参照して」って指示だしても、「そのファイルはありません」とか言ってくるようになりまして。
どうも、ブラウザ版onedriveからはそこにあるように表示されてるんですが、copilotには見えないという。
んでは、と、ブラウザ版onedriveで見ると一覧に表示されてるファイルを、ブラウザ版onedriveの上部検索枠からファイル名で検索しても、これが何故か検索にひっかからない出てこない。
……onedriveがダメになった？
じゃあ、とonedriveの設定開いて、フィードバックの送信を、と思ったら、
「An error occurred」てな表示が。
この状況で作業進められる気はしないなー。
0
PC関係 AIさんと画像振り分けについてご相談。
多少は、スコアに応じて明確なピンボケとかをはじけてきた気がする。
それはそれとして、株式優待とか配当目当てで若干、株を買ってたんですが、
米の中間選挙で共和党が大負けしたら、ポンと、反発値上がりしててびっくり。
0
PC関係 昨日の写真、30分で、20回くらいシャッター押したんですが、それで3300枚くらいjpgが撮れてまして。
写真管理は、いまだにSONYのPlayMemoryHomeを使ってるんですが、あまり画像表示とか早くないソフトウェアなので観たい写真を探すのもピントが合ってるかを確認するのもやたらかかるもので、3300枚の画像を目視確認しようとか無理を通り越して無茶という感じでして。
で、AIさんに「高速なビューワかつ、削除とかコピーが楽なのはない？」とか聞いて紹介されたやつは結構良い感じの表示速度だったんで、それはそれで良し。
良いんですが、根本的解決には程遠い、てことで、ローカルAIでピント判定する話になりまして。
すすめられるままにどっかの被写体判定ライブラリかなにかを利用して、ローカルAIで、画像中から被写体と背景を切り分けて、被写体区画のピントが合ってるかどうかを判定するコードをAIさんが書いたので、現在うちで滅多に使ってないGPU,RTX-2070Superが回っております。
……、いや、タスクマネージャー見るとGPU、最大で34%くらいだな？
元々水冷PCとはいえ、グラフィックカードのファン音もしないし？
3300枚くらい突っ込んでみたけど、ぼちぼち終わりそうだし、15分くらいで終わってる？
結果は、うーん、悩ましいなー。
0
カメラ 公園にカメラ持ってって30分程散歩。
トリミングとか多少の補正かけてます。
でも、こういうのがさらっと撮れるのは、楽しくていいですな。
高いカメラ買った甲斐がある、ということにしておこう。
主目的の飛行機は今年全然撮れてないけど。
などと遠く南の入間基地航空祭を思いつつ。
0
日記・コラム・つぶやき いかん、今日も夜更かしった。
明日は映画でも観に行こうかと思ってたんだけど、これでは朝のうちのは無理だな。
まーそれでもぼちぼち寝よう。
0
ゲーム いかん、昨日は本気で寝ぼけてたぽい。
月変わってから5-5片付けに行ってるし。
……これ、ちゃんと11月戦果になってる？
……たぶんなってる。
現在1-5,3-5,5-5クリア済みで戦果471。
前月引継ぎ分はほんのり損したかな？
クォータリーも今月まで残しちゃってたから、少し集中してやらんと。
0
ゲーム 気づけば、艦これのRO海域ほとんどほったらかしで。
ハロウィンイベントのマンスリーも泡食って今日片づけたところでして。
5-5片付けたら寝よう。
0
PC関係 職場でつかってるWindows10のPCを、いよいよ諦めてWindows11に。
いや、一応11対応可能なPCではあったんですが、11のインターフェースとか嫌いで、ずーっとESUでしのいでたんです。
ただ、Adobeとかで、10非対応て言われるのがちらほらあって。
ということで、WindowsUpdateでダウンロード始まったところで職場閉めて帰ってきちゃったんですが、休み明けに11になってるかなー？
0
日記・コラム・つぶやき 三沢、今年泊った宿で来年の予約をチェックしてみたんだけど、まだ来年三月いっぱいまでしか予約できない模様。
6ヶ月後まで、なのか、3月年度末まで、なのかどっちかわからんけど、どっちにしてもまだ予約はできないし。
0
日記・コラム・つぶやき 仕事の時は、背広着てることが多いんですが、もー夏物は無理でした。
午前11時くらいで外気温8度とか言われると、流石に外套が欲しくなります。
今日の所はてきとーなパーカー羽織ってなんとかしましたが、ぼちぼち冬物にきりかえなければ。
夏物より重くて肩凝るから嫌なんですけどねー
0
日記・コラム・つぶやき ちばてつや先生がお亡くなりになったのか。
「あしたのジョー」は言わずもがな。
「紫電改のタカ」「ハリスの旋風」とかも楽しませていただきました。
ご冥福をお祈りいたします。
0
日記・コラム・つぶやき スマートフォンが不調で、困っております。
具体的には「戻る」操作が効かない。
この状態が3-4ヶ月前から発生していて、往生しておりまして。
あれこれ試してダメだったので、初期化＆再インストールとか考えてるとこなんですが、使ってるスマートフォンにandroidOSアップデートが発表されたんで、それを待ってからか、と思いなおし。
ただ、全然アップデートの気配が無くてねえ……。
後継機種のはもう出たぽいんですが、いつになるやら。
0
日記・コラム・つぶやき ちょこっと片付け＆買い物。
映画「ストリートファイター/ザ・ムービー」でも見に行こうかとも思ったんですが、やたらと眠くてぐーたらしてました。
最近観に行こうかなーと思うと、朝一か夜中しかやってない映画ばっかりなんですが、なんでだ。
0
日記・コラム・つぶやき 今朝、寒くて、という程寒かった訳じゃないんだけど、朝5時頃起きてそのままだったので。
なんかやたら眠いような頭痛いような肩しんどいような。
とっとと寝て、明朝は灯油いれてタイマーセットしたファンヒータで暖かく寝てよう。
という訳で、おやすみなさい。
0
日記・コラム・つぶやき 東京、宿代の値上がりもなんですが、えきねっとのトクだ値が終了してて上京するコストが酷く上がっておりまして。
ここの所は、上京したとき新橋あたりのチケットショップでJR東日本の株主優待券買って使うことも多かったんですが、こちらも3000円前後から3000円代後半に。
盛岡南イオンのチケットショップだと4000円超えてましたし。
それでも岩手からだと若干は安くなる計算なんで、売れるんでしょうけど。
時折、職場とかでも「子供をディズニーランドへ連れて行かねばならぬ」なんて話を聞くのですが、総額考えたくないですなー。
とはいえ、iphoneもディズニーランドも人権レベルで、持ってない/行ってないと学校で村八分とかゆー話でしたし、田舎は辛いよ。
0
日記・コラム・つぶやき さーむーいー。
明朝、最低気温3度とか2度とか言うだけはありますわ。
毛布被ってても寒いったら。
明日を超えればまた少し暖かくなるみたいだけど、いい加減灯油調達しとかないといけませんな。
0
PC関係 なんか世界中のサーバがメンテに入ってるとかで、この日記も書き込めるのかどうか？
まあダメなら素直に布団被って寝ます。
0
PC関係 「ココログからWordPressへのブログ移行（後略）」を改定して、一応最終版としました。
必要そうな項目は一通り、おおざっぱにだけど書いたし書かせたし。
もう、いじる気は無し。
あとの細かいところはAIに相談してね。
という感じで。
0
日記・コラム・つぶやき
0
カメラ 天気も良かったので、車で一時間ほど北上してダム湖周辺の遊歩道とか歩いてきました。
で、OM-1M2の超望遠セットを担いでいったのですが、、、
割となんか写ってました。
コゲラとかアカゲラとかアオゲラとか。
シジュウカラぽいのも撮れてたはずだけど、探しきれませんでした。
だって、このカメラ、秒間25枚とか50枚とか撮れちゃうんで、今回、20-30回くらいしかカメラ構えてないのに、3500枚とかあるっていうんですもの。
保護色の野鳥とか、もうウォーリーを探してるかのようで。
で、タヌキ。
逃げないんだこいつが。
結局、手叩いて音だして追い払いました。
0
日記・コラム・つぶやき 指先が乾燥＆低温でひび割れてきました。
キーボードやらマウスに油が付くから、ハンドクリームを常時べったり、てのもなあ。
いかん、寒気してきた。
布団被って寝ます。
0
ゲーム copilot課金しなおしたんで、どの程度のことができるかなー？と思って、
「PC98のインペリアルフォースのクローンみたいなブラウザ動作ゲームをAI頼みで作れないか？」て相談したら、
「それくらいならできると思う」みたいなこと言われたので、
「じゃあ、ちょっとこんな仕様で」と、言ってみたところ、
「その仕組みは相性がいいですね」とか「その方向性は面白いですね」とかおだてられまくり、
copilotの提案をいちいち「ここはこう直して」とかこっちが指示だししはじめちゃって、
なんかルール仕様だけやたら巨大なのができてきたんで、ぼちぼち寝ます。
0
Uncategorized 11月15日（日）に、ヨコスカフレンドシップデーが開催予定とのことで、行って見ようかと検討していたのですが……。
宿たけえ。
都内で使いやすそうな所は暴騰or空きなし。
山手線沿線徒歩10分程度の範囲で、14日（土）→15日（日）の一泊が大体3万円超えてるんですが。
安くても2.5万円前後。
なにかでかいイベントでもあるの？
……て思って、前後の土曜泊も確認したら、そっちも3万円超えでしたよ。
どうしましょかね？
0
PC関係 仕事で使う用事もあったし、先日のココログ→wordpress移行記事も少々手直ししたいし、ということで、copilot使うために再課金。
移行記事に需要があるとはあんま思わないけど。
で、ふと思い立ち、アナログゲームのメカニクスをリサーチさせてみたり、
自作の旧作カードゲームのルールとカードを読み込ませてみたり。
かなり深くルールとか理解してるとようなので、本気で恐い。
0
カメラ えー、先日、横須賀オータムフェスタ行って、二度目の手荷物検査うけた時、
うっかりして、Lumix TX2Dをコンクリの床に落っことしてしまいまして。
結果、
・筐体あちこちに傷（後ダイヤル以外はまあ触らずに操作できそう）
・バックパネルと本体に微妙な隙間（当初はもっと空いてたのを押し込んだ）
・EVFをのぞき込んでもEVFに切り替わらず（壊れた当初はEVFしかダメで、タッチパネル/モニタのほうが表示されなかった。バックパネルを押し込んだら、逆になった。）
と、割と惨状。
もしかすると、後ダイヤル、もうちょっと軽かったかなあ？なんかひっかかるような？
で、メーカー修理、と思ったんですが、一応購入履歴を確認したところ、
買ったのは「三星カメラヤフー店」。
で、【10年間保証付き】て書いてあった。
規定を見ると、
【落下等におけるお客様の過失による故障の場合】
購入日〜3年目 修理代金（税別）価格の25％ 弊社負担
4年目〜7年目 修理代金（税別）価格の20％ 弊社負担
8年目〜10年目 修理代金（税別）価格の10％ 弊社負担
買ったのは2023年2月だったので、4年目～7年目のところか？
まー20%でも軽くなるなら御の字でありましょう。
あー、でも修理申し込み面倒くさいなー、とか思い、あちこちいじってたら、EVFはFn4/LVFボタンを押してたら切り替わった（当初は押してもダメだった）
バックパネルと本体の隙間も当初より感じなくなってる？
これだと修理ださなくてもまあ、使えなくもない、けど。。。
どうしようかねー？
0
日記・コラム・つぶやき ちょっと送迎の用事があって温泉方面へ。
待ってる間暇だから、と、川沿いの遊歩道をしばし散策。
……のつもりが遊歩道のコースをはずれて対岸の道路まで迷走。
結局、コースはずれたところまで戻り、30分程度のつもりが1時間ちょっと歩いてた。
まー良い散歩になったと思おう。
鳥でもいないかと思って、まーまー重いカメラ背負ってたのはほぼ無駄でしたが。
（上の写真はスマートフォン撮影）
0
PC関係 秋葉原HEYで数百円を1時間弱で溶かし、その後、オールドコンピューター系自主展示会？のマイコンインフィニットPRO68K見て、帰りました。
色々、すげーなー、という感想しかでないのがあちこちに。
まー見てもなにがなんだかわからない、て感じのも多かったんですが。
0
PC関係 する前に、先日投稿した「ココログからWordPressへのブログ移行手引きCopilot・ChatGPT・GeminiなどのAI活用版」に過去記事内の別記事へのリンクの修正について書き加え、再編集をcopilotにやらせました。
なもんで、出発が遅れて、結果10時過ぎに汐入駅到着。
カレー機関の行列に慄いて早々に諦め。
カレー一杯食べて、自衛隊のオータムフェスタを。
昼過ぎ、某氏と現地合流。
巡視船の行列に並んだものの時間的にギブアップしたり、艦これ看板を探したり。
その後、横須賀でちょっと飲んで、新橋でもうちょっと飲んで。
ということで、飲んだくれたのでとっとと寝ます。
0
日記・コラム・つぶやき 早起きしたんでぼちぼち活動限界。
明日は横須賀行ってカレーと艦船をみてくるつもりなので、とっとと寝ます。
U-NEXTで新作アニメみてたらおススメにR.O.Dがでてきたからつーて全話観ようとはしません。
なおOVA版。
あ、あと「ガールズ＆パンツァー最終章第5話」を観てきました。
0
PC関係 サイドバーの上部にくるくるぱたぱたするウィジェットを置きました。
今日はもう一個、ココログからwordpressへの移植参考書類を別記事で（copilotに整理させて）投稿しました。
この記事、精査してないし、実際にこれだけでやれるとは思わないんですが、引っかかりそうなところは大体指摘できてるはずなんで、後はAIさんに一ヶ月くらい課金して頼りまくれば、（私が3か月苦労したよりは）ずっと楽になんとかなるんじゃないかと思います。
という訳で、今日でcopilotの課金切れるはず。
さよーならー。
0
PC関係 この手引きは、ココログで長期間運営してきたブログをWordPressへ移し、できる限り元の記事、画像、投稿日、カテゴリー、記事同士のリンクを残したい人のための実務手引きです。
今回、私がココログからWordpressへ移行した際の実測では、MTバックアップに含まれる7,048記事を調査し、829件の画像参照と12種類のHTML構造を確認しました。実際の変換ルールとしては、おおむね6系統の画像表示方式に整理できました。
長年運営したブログには、大量の記事や画像があります。これらを一件ずつ確認し、画像をコピーし、記事本文のURLを書き換える作業をすべて手作業で行うのは現実的ではありません。
私は、「どうやってココログからwordpressにブログを移行するか」をAI（当初copilotの無課金で、のちにcopilot＝office365premiumに一ヶ月だけ課金）にバックアップの方法、どうやって画像をクロールするかを相談し、時にはAIの指示通りにPowershellでcopilotの作ったpythonスクリプトを実行しつつ、時にはAIの提案に駄目をだしつつ、試行錯誤して、ココログの仕様をわかる範囲で整理し、全過去記事の移行を行いました。
その3か月の過程は、私としてはかなり手間がかかったものの、面白かったものでもあり、「過程はともかくその労力の成果を残しておきたい」「AIの補助があれば、プログラムほぼ素人でも大量の記事、画像を一括処理すして移行できるのではないか」「同様の作業を行う人が（もしいれば）なんらかの目安になれば」と思い、本手引きを（これもAIによる補助を十分に利用して）作成し、公開することにしました。
この手引きでは、AIに作業を処理するスクリプトを作ってもらうことで、大量の記事や画像をできるだけ一括処理してWordPressへ移行します。
ただし、AIに移行作業を丸ごと任せるわけではありません。大量のデータの抽出、整理、照合、変換はAIとスクリプトに任せ、同一記事かどうか、表示画像と原画像の対応が正しいか、複数候補のどれを採用するかなど、判断が必要な部分は人間が確認します。
例えば、ココログから取得したMT形式バックアップはテキストファイルで、記事ごとに次のような情報が入っています。
TITLE: 記事タイトル
DATE: 09/12/2016 23:31:33
CATEGORY: 日記・コラム・つぶやき私は、AIに次のように依頼しました。
MT形式バックアップから、TITLE、DATE、CATEGORYを全記事分抽出して、CSVファイルに保存するPythonスクリプトを書いてください。
元のMTバックアップファイルは変更しないでください。このように、人間が目的を決め、AIに必要な処理を説明し、AIが作った処理を少量のデータで試し、結果を人間が確認してから全体へ広げます。Pythonは必須ではなく、必要な処理を実現する選択肢の一つです。
AIは便利ですが、必ず正しい回答をするわけではありません。こちらの指示を誤解することもあり、構文ミスがあって実行できないPythonスクリプトや、実行はできても意図とは違う処理をするスクリプトを出力することもあります。
また、「〇〇を処理するスクリプトを作ってください」と依頼したのに、スクリプトを作らず、一つ前の会話や調査結果を繰り返し説明し続ける場合もあります。
そのような場合は、AIの回答に無理に合わせず、違っていることを明確に伝えます。
指示したことと違います。
今回依頼した内容をもう一度確認し、考え直してください。説明を続けるのではなく、今回依頼したPythonスクリプトを作ってください。このスクリプトは、依頼した処理と違うように見えます。
入力、処理内容、出力を整理し、どこが依頼と一致しているか説明したうえで修正してください。AIが出したプログラムも、最初から正しいと決めつけません。dry-run、少量テスト、出力確認を行い、問題があればAIへ結果を戻して修正させます。
dry-run
↓
少量データで実行
↓
出力結果を確認
↓
問題があればAIへ戻す
↓
修正版でもう一度テストAIが自信ありげに答えていることと、その回答が正しいことは別です。一括処理では、一つの誤りが多数の記事や画像へ影響するため、AIの回答とスクリプトは必ず確認します。
AIとのチャットを長く続けると、試した方法、採用しなかった方法、現在使っているファイル、古い前提と新しい前提が混在し、AIが話を取り違えることがあります。チャットが長くなるにつれて、同じ説明を繰り返したり、すでに取り下げた方法を提案したりする場合もあります。
一つの大きな問題が解決したとき、作業が長時間になってきた、または会話が複雑になってきたと感じたときは、AIにここまでの作業記録をまとめさせます。
ここまでの作業内容を整理してください。
次の項目に分けてまとめてください。
1. 今回の目的
2. 使用したファイル
3. 判明したこと
4. 試した方法
5. うまくいかなかった方法と理由
6. 最終的に採用した方法
7. 作成したスクリプト、CSV、ログなどの成果物
8. 現在残っている問題
9. 次に行う作業
後で別のチャットから作業を再開できる内容にしてください。作成したまとめは、Notebookなど、あとから参照できる場所へ保存します。
同じチャットで話がかみ合わなくなってきた場合は、まとめを保存したうえで新しいチャットを開き、次のように再開します。
前回の作業記録を確認してください。
その続きから作業します。
まず現在の状態と、次に行うべき作業を確認してください。長時間の作業や込み入った内容で、会話の前提が増え、AIの回答が不安定になってきたときに、作業記録を区切りとして新しいチャットへ移る方法です。
次に何をすればよいか分からない、PowerShellやターミナルにエラーが表示された、CSVやログの意味が分からない、画面のどこを操作すればよいか分からない、といった場合は、推測で操作を続けずAIに相談します。
PowerShellやターミナルに表示された内容はコピーして、そのままAIへ貼り付けられます。処理結果のCSV、ログ、HTML、Pythonスクリプトなどをアップロードして確認させることもできます。画面操作が分からない場合は、スクリーンショットを貼り付けて質問できます。
このコマンドを実行したところ、次の結果になりました。
（PowerShellやターミナルに表示された内容を貼り付ける）
何が起きているのか、初心者にも分かるように説明してください。
次に入力するコマンドがある場合は、そのままコピーして使える形で示してください。このファイルは、今回の処理で作成されたCSVまたはログです。
想定どおりに処理できているか確認してください。
問題がある場合は、該当する行と理由を説明してください。現在この画面になっています。
次にどこを操作すればよいか、画面に表示されている項目名を使って説明してください。エラーを相談するときは、エラーメッセージの一部分だけを書き写すのではなく、実行したコマンドと、その後に表示された内容をできるだけ省略せず渡します。
ただし、スクリーンショット、ログ、設定ファイルなどをAIへ渡す前に、パスワード、APIキー、秘密鍵、個人情報などが表示されていないか確認してください。
分からない状態のまま推測で操作を続けないことも、一括移行における重要な安全対策です。
目的：一括処理の設定ミスによって、元の記事や画像を失わないようにします。
作業：元データを変更禁止の保存用フォルダーへ置き、調査や変換にはコピーを使います。変換結果も別ファイルへ保存します。
元データを保存
↓
作業用コピーを作成
↓
コピーだけを調査・変換
↓
変換結果は別ファイルへ保存完了状態：元データ、作業用コピー、変換結果、処理ログが別々に残っている状態です。
目的：スクリプトの誤動作や想定外のデータ形式を、小さい範囲で発見します。
1記事
↓
10記事
↓
1か月分または100記事
↓
全期間完了状態：各段階で変換前後を確認し、問題がないと判断してから次の規模へ進める状態です。
目的：実際にファイルを書き換える前に、何が変更対象になるかを確認します。
作業：AIに、変更予定件数、変換前後の例、未発見、複数候補、エラーを表示するdry-run機能を付けてもらいます。
完了状態：変更予定が人間の想定と一致し、誤変換が見つかっていない状態です。
目的：旧ココログの記事、画像、内部リンクを検索するときの基準となるURLを把握します。
作業：ブログURL、サイト最上位URL、HTTP形式、HTTPS形式を確認します。
https://buran.tea-nifty.com/blog/https://buran.tea-nifty.com/http://buran.tea-nifty.com/blog/HTTPとHTTPSは、人間には同じ記事に見えても検索や置換では別の文字列です。旧URLを調べるときは、HTTP、HTTPS、ドメイン部分だけの検索を行います。
完了状態：旧ブログで使われているURLの基本形を把握し、検索対象として記録した状態です。
取得したHTMLやパソコン上のフォルダー構造では、Web上のURLの「/」、Windows上のパスの「\」（これはバックスラッシュ、/の左右反転した文字として書きましたが、円マークで表示されることがあります）。HTTPとHTTPS、大文字と小文字、途中のフォルダー名にも表記差が生じます。
blog/images/sample.jpg
blog\images\sample.jpg少し違う書き方をまとめて検索するときは正規表現が役立ちます。正規表現自体を覚える必要はなく、検索条件をAIに作らせても構いません。ただし、正規表現で一致しただけで同一ファイルや同一記事と確定せず、候補として確認します。
古い記事では、文字コードや環境の違いによって、音符などの記号や特殊文字が正常に変換されない場合があります。AIに変換スクリプトを作らせる場合は、変換できない文字を勝手に別文字へ置換せず、記事名、元の文字、位置をログへ記録するよう指定します。
目的：記事タイトル、本文、投稿日、カテゴリー、画像HTML、旧画像URL、過去記事リンクを、後の一括処理に使えるテキストデータとして確保します。
作業：ココログからMT形式バックアップを取得し、変更禁止の元データとして保存します。画像ファイルそのものはMTバックアップには含まれません。
完了状態：元のMTバックアップが保存され、作業用コピーも用意できている状態です。
目的：MTバックアップに含まれない個別記事HTML、月別HTML、画像ファイル、HTMLから画像への参照関係をパソコンへ保存します。
作業：可能ならブログ部分だけでなく、サイト最上位から保存します。画像や共有ファイルがブログフォルダーの外側にある場合があるためです。
buran.tea-nifty.com
├─ .shared
├─ blog
│ ├─ 2006
│ │ └─ 08
│ │ ├─ index.html
│ │ └─ post-89ad.html
│ └─ images
└─ photos完了状態：個別記事HTML、月別HTML、画像フォルダーをローカルPCで確認できる状態です。
目的：記事情報を持つMTバックアップと、実ファイルや参照関係を持つHTTrack保存データを、後の対応表作成で結び付けられるようにします。
MTの記事情報
＋
HTTrackの保存情報
＋
実際の画像ファイル
↓
WordPress移行用の対応表完了状態：どの情報をどちらのデータから取得するかが整理されている状態です。
目的：元データ、作業中のデータ、対応表、スクリプト、処理結果を混在させないようにします。
MigrationProject
├─ backup_original
│ ├─ mt
│ └─ HTTrack
├─ work
│ ├─ mt
│ └─ HTTrack
├─ tables
├─ scripts
├─ output
├─ logs
└─ upload完了状態：元データを変更せず、すべての後工程を作業用フォルダー内で実行できる状態です。
目的：旧ココログ上の情報、HTTrackで保存されたローカルファイル、WordPress側の配置先と新URLを結び付け、AIとスクリプトによる一括処理を可能にします。
ココログでは、どの記事・画像だったか
↓
HTTrackでは、どのローカルファイルなのか
↓
ココログの記事HTMLでは、どう指定されていたか
↓
WordPressでは、どのフォルダーへ配置するか
↓
WordPress上では、どのURLになるか
↓
記事HTMLを、どのように書き換えるか対応表は確認用の一覧表だけではありません。画像のコピー、HTMLの変換、旧記事リンクの変換をスクリプトへ指示する中間データです。
完了状態：記事対応表、画像対応表、旧記事URL対応表の3種類を作成できる準備が整った状態です。
目的：MTバックアップの記事とHTTrackの個別記事HTMLを結び付け、その記事で実際に使われていた画像や旧URLをHTTrack側から調べられるようにします。
作業：タイトルと投稿日時、日時、タイトルと投稿日、本文冒頭の順に照合し、最後に必要なものだけを目視確認します。
結果：各MT記事について、対応する個別記事HTML、判断根拠、確実度、状態が記録されたCSVを作ります。
完了状態：状態が「OK」の記事は次の画像調査へ進め、「要確認」「複数候補」「未発見」は別に確認できる状態です。
目的：旧ココログの画像URL、HTTrackで保存された実画像、WordPressでの配置先、新URL、記事HTMLの書き換え内容を一つの行で結び付けます。
作業：MT側のimg srcとa href、HTTrack側の参照、保存された表示画像と原画像、画像形式、判断方法、確実度、WordPress配置先、新URL、状態を記録します。
旧ココログの画像URL
↓
HTTrackで保存された実画像
↓
WordPressでの配置先
↓
WordPress上の新画像URL
↓
MTバックアップ内で書き換えるURL結果：画像ごとに、コピー元、コピー先、表示用URL、クリック先URL、変換可否が分かるCSVを作ります。
完了状態：状態が「OK」の画像だけを第3部の一括コピーとHTML変換に使える状態です。
目的：画像名が変わっている場合や、表示画像と原画像が別の場合でも、誤った画像を記事へ割り当てないようにします。
1. 個別記事HTMLから直接取得
2. 月別index.htmlから取得
3. 元画像名で検索
4. 投稿日時に近い画像を候補にする
5. ファイルサイズと画像サイズを比較
6. 実際に画像を開いて確認作業：HTMLから直接判明した結果を優先し、日時やサイズによる推定は「推定」として記録します。
完了状態：確定、要確認、複数候補、推定、未発見が区別され、推定結果が確定扱いされていない状態です。
確認対象が多い場合は、画像対応表から「要確認」「複数候補」「推定」を抽出し、記事タイトル、投稿日、旧画像URL、ローカル画像、画像サイズ、判定状態と実画像をブラウザーへ一覧表示する目視確認用HTMLをAIとスクリプトで作れます。
すべての画像を見るのではなく、自動処理で確定できなかった画像だけを効率よく確認するための補助工程です。
目的：第4部で、記事本文中の旧ココログ記事リンクを新WordPress記事リンクへ一括変換するための設計図を作ります。
作業：旧URL、HTTP/HTTPS、対応する個別記事HTML、記事タイトル、投稿日、時刻、本文冒頭、判断方法、確実度、状態を記録します。
結果：各旧URLがどの記事を指していたかを確認できるCSVを作ります。新URLが確定している場合は新URLも記録します。
完了状態：OKの旧URLだけを変換対象にでき、要確認、複数候補、未発見を除外できる状態です。
目的：第2部の画像対応表を設計図として、画像ファイルをWordPress側へ配置し、記事本文の画像HTMLも新URLへ変換します。
画像対応表を完成
↓
WordPressでの画像配置先を決める
↓
ローカルPCにアップロード用フォルダーを作る
↓
対応表に従って旧画像をコピーする
↓
ローカルPCで確認する
↓
サーバーへまとめてアップロードする
↓
新しい画像URLを確認する
↓
MTバックアップ内の画像HTMLを書き換える注意：WordPressのメディアライブラリについて
この移行では、画像を wp-content/uploads/年/月/ へ直接配置し、記事本文のHTMLから画像URLを参照する方法を採用しました。WordPressのメディアライブラリへの登録は行っていません。大量の既存画像をメディアライブラリへ一括登録し、移植した記事と関連付ける方法については、本手引きでは検証していません。
完了状態：画像ファイルが新サーバーに存在し、変換済みMTバックアップの記事本文がその新URLを参照している状態です。
目的：各画像の保存先と公開URLを事前に確定し、コピー処理とHTML変換の基準にします。
wp-content/uploads/2016/09/sample.jpg
https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg作業：画像対応表に、サーバー上の配置先と新URLを記録します。
完了状態：OKの各画像について、コピー先と、記事HTMLへ記載するURLが決まっている状態です。
目的：サーバー上で大量の画像を一枚ずつ整理せず、ローカルPC上で完成形を作って一括アップロードします。
MigrationProject
└─ upload
├─ 2006
│ ├─ 08
│ └─ 09
└─ 2016
└─ 09
└─ sample.jpg作業：WordPressのuploads以下に対応する年・月のフォルダーを作り、画像対応表でOKの画像をコピーします。元画像は移動せず残します。同名ファイルは上書きしません。
完了状態：サーバーへ送る画像だけが、WordPress側と同じ相対フォルダー構造で整理されている状態です。
目的：記事をインポートする前に、記事本文が参照する画像URLを有効にします。
作業：ローカルPCで完成させた年・月フォルダーを、その構造のままサーバー側のwp-content/uploads以下へアップロードします。
結果：画像対応表に記載した新URLをブラウザーで開くと、対象画像が表示されます。
完了状態：少量の画像で新URL、表示内容、表示画像と原画像の区別を確認し、問題がない状態です。
WordPressで使われる画像HTMLは一種類ではありません。ブロックエディターから画像を挿入した場合は、画像ブロックを表す追加の要素やclassを含む別のHTMLになることがあります。
この手引きでは、大量の記事を一括変換しやすくし、ココログ独自の画像表示機能を残さないことを優先して、移行時には次のような単純なHTMLを採用します。これはWordPressで唯一の標準形式という意味ではありません。
<a href="新しい原画像URL">
<img src="新しい表示画像URL" alt="">
</a>クリック先を付けない画像はimgタグだけにします。表示画像と原画像を同じファイルへ統一する場合は、hrefとsrcが同じURLになります。
目的：ココログ独自の画像表示記述を除き、画像対応表で決めたWordPress側の新URLへ書き換えます。
作業：形式AからFを判定し、img src、a href、不要なonclick、class=”mb”、旧表示指定などを、画像対応表に従って変換します。
結果：記事中の画像が新サーバーの表示画像を参照し、必要な場合はクリックすると新サーバーの原画像が開くHTMLになります。
変換前:
<a href="http://buran.tea-nifty.com/.shared/image.html?/photos/uncategorized/sample.jpg" onclick="window.open(this.href); return false">
<img src="http://buran.tea-nifty.com/blog/images/sample.jpg" alt="">
</a>
変換後:
<a href="https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg">
<img src="https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg" alt="">
</a>変換前:
<a href="http://buran.tea-nifty.com/photos/uncategorized/sample.jpg">
<img src="http://buran.tea-nifty.com/blog/images/sample.jpg" alt="">
</a>
サムネイルを維持する場合:
<a href="https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg">
<img src="https://www.buran-works.com/wp-content/uploads/2016/09/sample-display.jpg" alt="">
</a>class=”mb”を削除し、hrefとsrcを画像対応表の新URLへ変更します。
hrefとsrcが同じ旧画像を指す場合は、両方を同じ新URLへ変更します。
表示用サムネイルとクリック先の原画像を区別します。サムネイルを維持するか、表示も原画像へ統一するかを画像対応表で決めます。
クリック先がないため、基本的にはimg srcだけを新URLへ変更します。
目的：サーバーへ画像を配置しただけでは、MTバックアップの記事本文は旧ココログ画像を参照したままです。画像対応表を使い、記事本文の旧画像HTMLをまとめて新URLへ書き換えます。
使うもの：作業用MTバックアップ、画像対応表、WordPressサーバーへ配置済みの画像、新URLの確認結果です。
MTバックアップの記事本文
旧ココログ画像URL
↓
画像対応表を参照
↓
WordPress上の新画像URLへ変換
↓
ココログ独自のHTML指定を整理
↓
変換済みMTバックアップを別ファイルとして保存作業：単純にドメインを置換するのではなく、画像ごとにimg src、a href、表示画像、原画像、_thumbの扱い、外部画像、未発見状態を画像対応表から判断して変換します。
結果：元ファイルとは別に、画像HTMLがWordPress側の新URLへ変換されたMTバックアップと、変換件数、未変換件数、エラーを記録したログが作成されます。
完了状態：dry-runと10記事テストで変換内容を確認し、旧URLの残存が意図したものだけになっている状態です。
画像対応表を使い、MT形式バックアップ内の画像HTMLをWordPress向けの単純なHTMLへ変換するPythonプログラムを書いてください。
条件:
・記事表示用画像URLを対応する新URLへ変更
・クリック先URLを対応する新しい原画像URLへ変更
・.shared/image.html?/を使う旧リンクを残さない
・onclick、class="mb"、不要な古い表示指定を削除
・元のalt属性があれば維持
・_thumbは対応表の指定に従って維持または原画像へ統一
・外部画像、未発見、複数候補は自動変換しない
・HTML解析を優先し、必要に応じて正規表現を補助的に使う
・文字コードを維持し、変換できない記号を勝手に置換せずログへ記録
・元のMTファイルは変更しない
・変換結果は別ファイルへ保存
・最初はdry-run
・変換前後の例、変換数、未変換数、エラー数を記録
・最初の10記事だけでテスト可能にする記事本文に残った旧ココログ記事へのリンクを、新WordPress記事へのリンクへ変更します。画像だけを移行しても、記事内リンクが旧サイトを指したままでは移行は完了しません。
完了状態：OKと確認された旧記事リンクが新URLへ変換され、未確定リンクは別一覧として残っている状態です。
私が実際に移行作業を行ったときは、いったんWordPressへ記事をインポートしてから、記事本文中の旧ココログURLを書き換える方法しかないと思っていました。
そのため、まずMTバックアップをWordPressへ読み込み、WordPress側で実際に作成された記事URLを取得しました。その後、旧ココログ記事URLと新WordPress記事URLの対応表を作り、SQLを生成してphpMyAdminから記事本文を一括更新しました。
WordPressへ記事を読み込む
↓
WordPressが実際に作った記事URLを取得
↓
旧URLと新URLの対応表を作成
↓
SQLを生成
↓
phpMyAdminで記事本文を一括更新
↓
Search Regexで旧リンクの残りを確認これは実際に行った方法です。しかし作業を進めたあとで、「WordPressへインポートする前に、MTバックアップ側の記事リンクを新URLへ書き換えておけば楽だったのではないか」と気づきました。
そこで、この手引きでは、実際に行った上記のインポート後のデータベース更新方法を紹介せず（確実と思われますが手間も作業の面倒さも素人には重かったと感じたので）、後から考えたMTバックアップ側を先に修正する方法を説明します。
目的：WordPressへインポートする前に、MTバックアップの記事内リンクをできるだけ新WordPress URLへ変換し、インポート後にデータベースを直接更新するリスクや手間を減らします。
使うもの：作業用MTバックアップ、記事対応表、旧記事URL対応表、WordPressのパーマリンク設定です。
MTバックアップから旧記事URLを抽出
↓
HTTrackでリンク先記事を特定
↓
記事タイトルと投稿日を取得
↓
新サイトの記事URL（予定）を決める ※パーマリンク設定に依存
↓
旧URLと新URLの対応表を作る
↓
OKのリンクだけMTバックアップ内で書き換える
↓
変換済みMTバックアップを別ファイルへ保存結果：旧ココログ記事リンクが新WordPress URLへ変換されたMTバックアップが作られます。
WordPressへインポートする前であっても、次の特性を利用することで、移行後の新URLを高い精度で予測し、対応表を作ることができます。
/%postname%/）」などにしている場合、タイトルから新URLを事前に算出することが可能です。-2 や -3 などの連番を付与します。-2」が含まれるURLを検索すれば、該当記事を容易に特定して後から個別に対応表を修正・確認できます。注意：この方法は全記事の実移行で使用した方法ではありません。また、WordPressが予想どおりのURLを作ることを、少数記事のテストインポートで先に確認する必要があります。
完了状態：OKのリンクだけが新URLへ変換され、要確認、複数候補、未発見が変換されずに記録されている状態です。
目的：同じタイトルの記事を別の記事へ誤ってリンクさせないようにします。
タイトル＋投稿日＋投稿時刻
タイトル＋投稿日
投稿日＋本文冒頭
表記ゆれを整えたタイトル
手動確認完了状態：同名記事でも、判断根拠と確実度が記録され、OKのものだけが変換対象になっている状態です。
目的：リンク変換スクリプトに、どの旧URLをどの新URLへ置き換えるかを明確に指示します。
結果：旧URL、HTTP/HTTPS、記事タイトル、投稿日、新URL、判断方法、確実度、状態を含むCSVが完成します。
完了状態：元の旧URLを残したまま、OKの行に新URLが入り、未確定行と区別されている状態です。
目的：対応表でOKになった記事リンクだけを一括変換します。
作業：本文中の説明用文字列ではなく、a hrefのリンク先を優先して置換します。HTTP、HTTPS、表記ゆれを確認し、必要に応じて正規表現を補助的に使います。
結果：新記事URLへ変換されたMTバックアップと、変更した記事数、リンク数、未変換リンク、エラーを記録したログが作られます。
完了状態：10記事テストでリンク先が正しく、別記事への誤リンクがない状態です。
目的：記事をインポートしたあとに大量のリンク切れが発生しないよう、必要な前工程が終わっているか確認します。
完了状態：テストインポートに使える変換済みMTバックアップが用意できている状態です。
目的：ここで行うのは新たな一括変換ではなく、変換漏れを見つける検査です。
作業：旧ドメイン、.shared、image.html、window.open、class=”mb”、photos/uncategorized、blog/images、file:///、_thumbなどを検索します。一致箇所が説明文なのか、変換すべき画像HTMLやリンクなのかを確認します。
結果：修正が必要な残存記述、意図的に残す記述、要確認記述を区別した一覧を作ります。
完了状態：変換漏れが解消されるか、要確認として管理されている状態です。
目的：全記事を読み込む前に、代表的な画像形式、リンク形式、文字コードの問題を発見します。
作業：画像なし、通常画像、.shared形式、class=”mb”、_thumb、複数画像、外部画像、過去記事リンク、同名タイトル、音符や特殊文字を含む記事を選びます。
10記事
↓
100記事または1か月分
↓
全記事次へ進む条件：タイトル、投稿日、カテゴリー、本文、画像表示、画像クリック先、過去記事リンク、記事URL、文字化け、改行、スマートフォン表示に問題がないことを確認します。問題があれば、記事数を増やす前に対応表やスクリプトを直します。
目的：変換済みの記事データをWordPressへ登録します。
作業：MT形式に対応したWordPressの読み込み機能で、変換済みMTバックアップを取り込みます。※この手引きの方法では、画像をあらかじめサーバーへ配置し、記事本文の画像URLも書き換えているため、インポートの際、「添付ファイルをダウンロードする」といった選択肢が表示された場合は、原則としてチェックを外します
結果：記事、投稿日、カテゴリー、本文がWordPressへ登録され、記事本文から配置済み画像と新記事URLを参照します。
完了状態：読み込み件数と元記事数の差を確認し、重大な欠落、重複、文字化け、リンク切れがない状態です。
WordPressへ移行した結果と、移行前に作った対応表、変換結果、ログが一致しているか確認します。問題が見つかった場合は、WordPressの記事を一件ずつ直すのではなく、原因となった対応表や変換処理まで戻って修正します。
完了状態：記事、画像、記事内リンクの主要検査を終え、残った問題が修正済みまたは未解決一覧として管理されている状態です。
対応表を修正
↓
画像フォルダーを作り直す
↓
MTバックアップを変換し直す
↓
再検査
↓
再テストWordPress上だけを手修正すると、再インポートしたときに同じ問題が戻る可能性があります。可能な限り対応表、スクリプト、変換済みMTバックアップへ修正を戻します。
Pythonは、この移行に必須ではありません。大量ファイルの検索、CSV作成、HTML変換、画像コピーなどをAIに作らせたプログラムで自動化する場合に使います。
ここではPythonの文法を学ぶのではなく、AIが作ったPythonプログラムを自分のパソコンへ保存し、実行するための最低限の操作を説明します。
Pythonのプログラムは、設定画面のボタンではなく、文字でパソコンへ命令を入力する画面から実行します。この画面を一般にターミナルと呼びます。
Windowsではスタートメニューで「PowerShell」または「ターミナル」を検索して開きます。macOSでは「ターミナル」を開きます。
PS C:\Users\名前>この記号の後ろへコマンドを入力し、Enterキーを押します。
コマンドとは、ターミナルでパソコンへ与える文字の命令です。次は設定項目ではなく、Pythonのバージョンを表示させるコマンドです。
Python --versionWindowsの環境によっては、次を使います。
py --versionPythonが利用できる状態ならバージョンが表示されます。エラーが表示された場合は、入力したコマンドと表示結果をコピーし、AIへそのまま渡します。
AIが返したPythonプログラムをテキストファイルとして保存し、ファイル名の最後に.pyを付けます。
make_image_table.pymake_image_tableがファイル名、.pyがPythonプログラムであることを示す拡張子です。
MigrationProject
└─ scripts
└─ make_image_table.pyscriptsは、AIが作った処理用プログラムをまとめて置くフォルダーです。この名前でなければPythonが動かないわけではありません。
C:\MigrationProject\scripts\make_image_table.pyフォルダーとディレクトリは、どちらもファイルをまとめて置く場所を意味します。この手引きでは通常「フォルダー」と呼びます。コマンドの説明では「ディレクトリ」という言葉が使われます。
現在ターミナルで作業対象になっているフォルダーを「カレントディレクトリ」と呼びます。
PowerShellを開いた直後に次のように表示されているとします。
PS C:\Users\名前>Pythonプログラムを保存したC:\MigrationProject\scriptsへ移動するには、次を入力してEnterキーを押します。
cd C:\MigrationProject\scriptscdは、現在作業しているフォルダーを変更するコマンドです。移動できると表示が次のように変わります。
PS C:\MigrationProject\scripts>macOSでも、ターミナルでcdを使ってプログラムを保存したフォルダーへ移動します。ただし、フォルダーの場所を表す書き方はWindowsと異なります。分からない場合は、フォルダー画面とターミナル画面のスクリーンショットをAIに見せ、移動用コマンドを作らせます。
Python make_image_table.pyWindowsの環境によっては、次を使います。
py make_image_table.pyこれは「Pythonを使って、現在のフォルダーにあるmake_image_table.pyを実行してください」という意味です。
PS C:\Users\名前> cd C:\MigrationProject\scripts
PS C:\MigrationProject\scripts> Python make_image_table.pyこのプログラムについて、次を説明してください。
1. 入力として読むファイル
2. 作成または変更するファイル
3. 出力先のフォルダー
4. 元ファイルを上書きする可能性があるか
5. dry-runの実行方法
6. 正常終了したときに表示される内容
7. エラー時に確認する内容実行後は、CSV、ログ、HTMLなどの出力ファイルをAIへアップロードし、想定どおりか確認させることもできます。
AIからpip install ...と指示された場合、それはPythonへ追加機能を入れる操作です。何を導入するのか、なぜ必要なのか分からない場合は、実行前にAIへ説明させます。
プログラムだけでなく、次の内容も初心者向けに説明してください。
1. どのファイル名で保存するか
2. どのフォルダーへ保存するか
3. PowerShellまたはターミナルをどう開くか
4. cdでどのフォルダーへ移動するか
5. 実際に入力するコマンド
6. 実行すると何が作成されるか
7. dry-runの方法
8. エラーが出た場合に、どの表示をAIへ渡せばよいか昨日の帽子画像、メキシカンハット、て言うそうなんですよ。
昔々、MZ-2000のカタログ等に昨日の画像のような点群で描かれた３Dの帽子？画像が載っておりまして。
ただ、当時、プログラムで動いてたところは見た記憶がない。
なもんで、copilotに画像を見せて「こんなのを描画するスクリプト書いて」て言いました。
最終的に、copilotに作ってもらったのがこちら。
メキシカンハット くるくる比較・開始角選択版
ここにたどり着くまでに結構四苦八苦したけど、結構面白かった。
最初にでてきたのは、緑色の直線で頂点を四角形を結んだワイヤーフレームの３Dで
当時っぽいけど、元画像は点群なので違うだろう、と。
で、点群で描いてもらったんだけど、今度は山の稜線の向こう側にあるはずの点が見えるプログラムで。
元画像はどうにかして陰面処理してるようだ？どうやってる？
つーて、copilotがつくってくるスクリプトにダメ出しし続けて。
この頃は、copilotの陰面処理の提案が割とぽんすけで……
……というあたりはもう延々長いので、copilotにまとめさせました。
以下、暇な人向け。
昔見たMZ-2000のデモ画面には、帽子のような不思議な立体が描かれていた。その画像をブログ上で再現しようと始めた試みは、やがて当時の描画アルゴリズムを推理する作業へ発展していった。
昔見た帽子状CGを探したところ、MZ-2000のデモ画像を発見。黒背景に緑色の立体を描くJavaScript版の制作を始めた。
正方形平面の格子点に高さを与え、隣接する点を線で結んだ。最初は一般的なワイヤーフレーム曲面として実装した。
中心からの距離で標高を決定。中央高原、浅い窪み、山麓の谷、外輪山、外周の谷を複数の関数で合成した。
斜め視点だけでは形を判断しにくいため、真横視点を追加。正方形の対角線に沿った標高を見ながら、山谷の位置と幅を調整した。
元画像は格子線よりも、高密度な点の集合に見えた。そこで線で結ぶ方式をやめ、計算した格子点を1ドットずつ表示する方式へ変更した。
元画像では陰になる部分が見えないため、画素ごとの奥行きを記録。同じ画素に複数の点が重なった場合は、最も手前の点だけを残した。
Zバッファが正しく働いても、1ドットが隠せるのは同じ画素の点だけだった。格子の隙間から、曲面の裏側にある点が見えてしまった。
そこで私から、四つの格子点で囲まれたセルを面として塗りつぶせないかと提案。点単位から、ポリゴン的な面単位の処理へ発想を変えた。
格子セルを奥から手前へ処理し、投影したセル内部を黒く塗った後、四隅の格子点を緑色で打ち直す方式を実装した。
Canvasは斜めの線や多角形の縁をアンチエイリアス処理し、境界画素を半透明色として合成する。このため、黒い面を重ねても縁の緑が暗く残り、消し残りのように見えた。
さらに表示だけを拡大すると、Canvas内部の描画結果がCSSサイズへ引き伸ばされるため、半透明の境界画素やドットの濃淡が一層目立った。Canvasは内部寸法とCSS表示寸法が異なると拡大縮小される。
なお、image-rendering: pixelated や imageSmoothingEnabled = false は画像の拡大補間を抑える設定であり、Canvasのパス描画そのものにかかるアンチエイリアスを完全に無効化するものではない。
Canvasへ直接描いて消す方式をやめ、ピクセル配列上で最終色を確定してから一括表示した。RGBA値を直接扱うことで、半透明の境界を作らず完全な黒と緑にできた。
試行錯誤中、元のデモと思われるBASICリストの写真を発見。Copilotに解読させ、モデル形状、視点、座標計算、描画順を推定した。
Copilotの解析では、元の処理は浮動地平線法に近いとされた。画面各列の上下の可視境界を更新し、その内側へ入る後続の線を描かない方式だった。
浮動地平線法は英語で Floating Horizon Algorithm と呼ばれる一般的な隠線消去法で、二変数関数の曲面を線画として表示する用途に使われる。
同じ帽子形状と視点を使い、セルを黒く塗る面処理と、BASICリストを参考にした浮動地平線法をそれぞれHTMLで再現した。
浮動地平線法は軽量だが、走査方向と視点の関係が重要だった。想定された固定視点では有効でも、自由に回転させると隠線判定が破綻しやすい。
MZ-2000の三つのグラフィックプレーンへ、方位角の異なる三枚を事前描画。表示ページの切替だけで回転して見せる案を考えた。
三枚を「1→2→3→1」と循環させる回転版と、「1→2→3→2→1」と往復させる首振り版の二種類を構想した。
セル方式では、各セルの座標変換、四角形内部の黒塗り、格子点の再描画が必要になる。ブラウザでは動いても、当時のZ80には重すぎた可能性がある。
浮動地平線法なら、画面各列の上端と下端だけを記録すればよい。全面を塗る必要がなく、セル方式より少ない計算量とメモリで隠線を除去できる。
この試みは、正方形格子を線で結ぶワイヤーフレームから始まった。
元画像との違いから点群描画へ移り、Zバッファによる奥行き判定も追加した。しかし、そこで「点では面の向こう側を隠せない」という根本的な問題に気付いた。
手前の格子点が1ドットなら、隠せるのも同じ画素にある1ドットだけである。格子点の間にある本来の地表面には面積がないため、その隙間から奥の点が見えてしまう。
そこで私から、格子点で囲まれたセルを面として塗りつぶす方式を提案した。これは、点単位の可視判定から、ポリゴン的な面処理への大きな転換だった。
ところが、Canvasへ直接黒い多角形を描いて消すと、境界の緑が暗く残った。原因は単純な「黒塗り不足」ではなく、斜めの輪郭に対してCanvasが自動的に行うアンチエイリアスと半透明合成だった。
そこで、描画途中のCanvasへ黒や緑を重ねるのではなく、メモリ上のピクセル配列で最終的な色を確定し、完成画像だけを一括表示する方式へ変更した。これにより、消し残りや不均一な明るさを解消できた。
そして最大の転機となったのが、元のBASICリストらしき写真の発見である。Copilotによる解析から、元プログラムは浮動地平線法に近い処理を使っていた可能性が高まった。
こうしてテーマは、単に「帽子らしい形を作る」ことから、1980年代の8ビット機が、限られた計算能力で立体をどう表現したのかを推理することへ変わっていった。
4
PC関係 ここ数日、「課金切れるまでにcopilotになんか作らせて、このブログのサイドバーのとこに置いてみよう」と思い、あーだこーだやっておりました。
で、昔のMZ-2000のデモで見たことのある帽子の３Ｄ画像、あれを再現したいな、と思い立ち。
調べてみるも、webで見つかったのはカタログのぼやけた写真だけ（この時点では）。
で、copilotに丸投げで「こんな感じの３D物体を点群で画像表示するhtml＋Javascriptを作ってちょうだい」つーたら色々作ってくれまして。
今、こんな感じになりました。
もー大体、気は済みました。
0
PC関係 ブログの移植、という目的は達成したし、copilotさん目当てにMicrosoft365Premiumを課金し続けるのは違うだろう、ということで10/09で課金切れしてそのまま、ということにしました。
残り期間でもうちょっとなんか作れないかなー、と思い、ちまちまやってます。
元画像の資料どっかに無いかしら？
0
日記・コラム・つぶやき 朝起きて、朝一で映画見に行くのは断念。
見ようかな、と思っていた映画が朝一番と夜しかやってない、てのはちょっと勘弁して欲しいなあ。
んじゃあ、晴れてたのでカメラ持って、鳥でも撮ろうか、つーて車で50分くらいの所の湖に。
したら着いた頃には曇ってて、そこそこ撮ってはみたものの微妙な写り具合で。
道の駅でカレー食って帰りまして。
で、今日行かないとU-NEXTのポイント交換で買ったチケットを使う余裕は無いので、
なんか観てこよう、つーて、190分の超大作とかもあったんですが、120分以内の膀胱に優しい映画のほうがいいか、てことで犬の洋画を。
犬がもうちょっと頑張ってくれればなあ……。
0
日記・コラム・つぶやき 早起きして、少々用事を片付け……ようとしたら、結構混んでて。
で、ちまちまっと作業しては、しばし待て、の繰り返しでくたびれました。
寒いし眠いし、今日はとっとと寝ます。
0
PC関係 どうも「最初にココログから画像とかhtmlをクロールするのに失敗してたんじゃないか？」という気がしてきました。
いや、ほとんどいないとは思うんだけど、ココログからwordpressへのブログ移植を志す人が今後いる場合に備えて、ここ3か月の四苦八苦をまとめてみようと思いましてね？
んで、手順をもう一度確認、と思って、
１．記事本体はMT形式でココログから全件出力（ただしこれはテキストソースのみ）
２．HTTRACKで画像をクロール
と、ここまでやった時点で、最初のクロール結果と随分違うことになって。
……これ、ちゃんとクロールできてれば、ここ3か月の四苦八苦の半分くらいは無くなっていたのでは？
という気がしてきてるところ。
まあ実際には、その四苦八苦の結果、最短手順に至れてるのだと思うのですが。
……だったらいいなあ。本当にorz
0
日記・コラム・つぶやき という訳で、こちらにブログ移転しました。
ココログで書いてたブログがGoogle検索にひっかからなくなって、
自作のカードゲームやらなにやらの情報も誰も探せない、
自分で自分の旅行記録を確認しようにも見つからない、と困りまくったんで、
レンタルサーバーでドメイン取って移転してきました。
Google Search Console も登録しましたし。
画像も貼り放題、変なhtmlも貼り放題ですよう、たぶん。
（サーバ容量と処理能力の範囲内で）
0
日記・コラム・つぶやき 毛布足しました。
ぼちぼち最低気温一桁が見えてきたんで、色々足しております。
早いね、本当。
0