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関係 26/10/14改稿
この手引きは、ココログで長期間運営してきたブログをWordPressへ移し、できる限り元の記事、画像、投稿日、カテゴリー、記事同士のリンクを残したい人のための実務手引きです。
HTML、Python、SQLなどに詳しくない人でも進められるよう、専門用語は必要な場面で使い、その直後に意味を説明します。専門用語を覚えることが目的ではありません。AIへ何を調べさせ、何を作らせ、どこを人間が確認するかを理解することが目的です。
今回の実測例では、MTバックアップに含まれる7,048記事を調査し、829件の画像参照と12種類のHTML構造を確認しました。実際の変換ルールとしては、おおむね6系統の画像表示方式に整理できました。
この手引きでは、移行作業を次の6部に分けます。
第1部 旧ココログを保存し、サイトの構造を確認する第2部 記事・画像・旧URLの対応表を作る第3部 ココログの画像をWordPress向けの形へ変換する第4部 記事内の過去記事リンクを新サイト用に直す第5部 画像と変換済み記事をWordPressへ移す第6部 移行結果を確認し、残った問題を直す本手引きには、実際に行った方法だけでなく、保存データから確認した内容、保存結果をもとにした推定、AI活用版として提案する未検証の方法も含まれます。未検証の方法は、そのことが分かるように記載します。
移行作業では、次のような多数のファイルを扱います。
ココログから取得したMTバックアップHTTrackで保存した旧サイト記事の対応表画像の対応表旧URLと新URLの対応表AIに作成してもらった処理用プログラム処理結果の記録書き換え後のMTバックアップWordPressへ送る画像一括処理の設定を一つ間違えるだけで、多数の記事を書き換えてしまう可能性があります。
必ず次の順番で作業します。
元データを保存↓作業用コピーを作成↓コピーだけを調査・変換↓変換結果は別ファイルへ保存AIが作った処理用プログラムも、最初から正しく動くとは限りません。
1記事↓10記事↓1か月分↓全期間の順で試します。
dry-run とは、実際にはファイルを書き換えず、何件が変更対象になるか、どのように変わる予定かだけを確認する試験実行です。
AIには、必ず次の条件を付けます。
本手引きでは、筆者が実際に移行した旧ブログを例にします。
移行時点のブログURLは次のとおりです。
https://buran.tea-nifty.com/blog/サイトの一番上のURLは次のとおりです。
https://buran.tea-nifty.com/ただし、長年の記事データにはHTTP時代のURLも残っていました。
http://buran.tea-nifty.com/blog/http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttp://buran.tea-nifty.com/blog/images/sample.jpgそのため、この手引きではHTTPとHTTPSの両方を旧ココログURLとして調べます。
次の2つは、人間には同じ記事に見えても、文字列としては別URLです。
http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttps://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlサイト側の設定によっては、HTTPからHTTPSへ自動転送され、同じ記事や画像が開く場合があります。しかし、検索や一括置換では別の文字列として扱われます。
したがって、旧URLを探すときは次の3種類を確認します。
http://buran.tea-nifty.comhttps://buran.tea-nifty.comburan.tea-nifty.com最後にサイト名だけでも検索すれば、HTTPとHTTPSのどちらで残っていても見つけやすくなります。
https://buran.tea-nifty.com/blog/2006/08/post-89ad.htmlは、次のように分けて考えます。
https:// HTTPかHTTPSかを示す部分
buran.tea-nifty.com サイトを表す部分
blog/ ブログ部分の名前
2006/08/ 記事の年月
post-89ad.html 個別記事のファイル名すべてのココログが ○○○.tea-nifty.com/blog/ という形とは限りません。tea に相当する部分や、blog に相当する部分が異なる例もあるため、自分のブログの実URLを確認してください。
ココログからWordPressへの移行を行います。
まずMTバックアップとHTTrack保存データを調査し、旧ココログサイトのURL構造を確認してください。
筆者の例:https://buran.tea-nifty.com/https://buran.tea-nifty.com/blog/
ただし過去記事には、http://buran.tea-nifty.com/http://buran.tea-nifty.com/blog/も残っている可能性があります。
http:// と https:// の両方を調べてください。URL先頭のhttp/https以外が同じものは、同じ記事または画像の候補として記録してください。
buran、tea-nifty.com、blogに相当する部分は、他のココログでは違う可能性があるため固定しないでください。
この段階では何も書き換えず、見つかったURLの種類と構造だけを報告してください。MTバックアップは、記事をまとめて保存したテキストファイルです。主に次の内容が入っています。
ただし、画像ファイルそのものは入っていません。
元ファイルは、例えば次の名前で保存します。
cocolog_mt_original.txt直接編集しないでください。
MT内の記事は、例えば次のような形です。
TITLE: 記事タイトルDATE: 09/12/2016 23:31:33CATEGORY: 日記・コラム・つぶやきBODY:記事本文HTTrackは、WebサイトをHTMLや画像を含めてパソコンへ保存するソフトです。
ブログが次のURLでも、
https://buran.tea-nifty.com/blog/可能ならサイトの一番上から保存します。
https://buran.tea-nifty.com/画像や共有ファイルが /blog/ の外側にある場合があるためです。
保存結果は、例えば次のようになります。
buran.tea-nifty.com├─ .shared├─ blog│ ├─ 2006│ │ └─ 08│ │ ├─ index.html│ │ └─ post-89ad.html│ └─ images└─ photosMTバックアップ 記事タイトル 投稿日時 記事本文 ココログ上の画像URL 過去記事へのリンク
HTTrack 月ごとの一覧HTML 個別記事HTML パソコン内での画像参照先 実際に保存された画像ファイル移行の中心作業は、この2種類の情報を結び付けることです。
MTの記事情報＋HTTrackの保存情報＋実際の画像ファイル↓WordPress移行用の対応表MigrationProject├─ backup_original│ ├─ mt│ └─ httrack├─ work│ ├─ mt│ └─ httrack├─ tables├─ scripts├─ output├─ logs└─ uploadbackup_original：絶対に変更しない元データwork：調査や変換に使うコピーtables：記事・画像・URLの対応表scripts：AIが作った処理用プログラムoutput：変換後のMTファイルlogs：処理結果やエラーの記録upload：WordPressへ送る画像主に次の3種類を作ります。
記事対応表MTの記事 → HTTrackの個別記事HTML
画像対応表旧画像URL → 保存画像 → WordPress配置先 → 新画像URL
旧記事URL対応表旧記事URL → 記事タイトル・投稿日 → 新記事URL画像や旧記事リンクを正しく調べるには、MT内の記事がHTTrackのどの post-xxxx.html に対応するかを特定する必要があります。
照合は次の順で行います。
例えば、MT側が次の場合、
TITLE: Ｃ７１申し込みDATE: 08/19/2006 14:02:02HTTrack側の月別ページで、
2006-08-19 14:02↓post-89ad.htmlと分かれば、同じ記事として対応表へ記録します。
index.html の場所AIが扱いやすいよう英語の列名を使う場合でも、読者は意味を理解できれば十分です。
画像対応表には次を記録します。
どの記事にあった画像か↓MTに書かれた表示画像URL↓MTに書かれたクリック先URL↓HTTrackの記事HTMLに書かれた参照先↓実際に保存された表示画像↓実際に保存された原画像↓WordPressでの配置先↓新しい画像URLここで重要なのが、img src と a href です。
img src：記事中に表示する画像のURLa href：画像をクリックしたときの行き先この2つは同じとは限りません。
画像対応表には少なくとも次を記録します。
img srca hrefimg srca href正しい画像を特定するときは、次の順番を使います。
1. 個別記事HTMLから直接取得2. 月別index.htmlから取得3. 元画像名で検索4. 投稿日時に近い画像を候補にする5. ファイルサイズと画像サイズを比較6. 実際に画像を開いて確認HTMLから直接分かった結果と、更新日時から推定した結果を同じ扱いにしません。
個別記事HTMLに次の記述がある場合、
<a href="../../../.shared/image8e08.jpg?/photos/uncategorized/c71cut.jpg">次の対応が分かります。
ココログ上の原画像名c71cut.jpg
HTTrackが保存した原画像.shared/image8e08.jpgHTMLから見つからない場合だけ、更新日時、ファイルサイズ、画像の縦横サイズ、目視確認へ進みます。
MT形式バックアップ、HTTrackの月別index.html、個別記事HTML、画像フォルダーを解析するPythonプログラムを書いてください。
目的:MTバックアップ中の画像参照と、HTTrackで保存された画像を対応付けること。
重要:・img srcは記事に表示する画像・a hrefはクリック先・表示画像と原画像が別の場合がある・.shared/imageXXXX.jpgへ名前が変わっている場合がある
照合順:1. 個別記事HTML内の参照2. 月別index.html内の参照3. 画像ファイル名一致4. 投稿日時と更新日時が近い候補5. 手動確認候補
対象:・.shared/image.html?/ を使う形式・window.openを使う形式・photos/uncategorizedとblog/imagesが別の形式・class="mb"を使う形式・_thumbを使う形式・imgタグだけの形式・外部画像・file:/// で始まる壊れた参照
条件:・元データは変更しない・未発見は別一覧にする・複数候補は自動確定しない・推定結果を確定結果と同じ扱いにしない・最初の10記事だけでテストできるようにする記事本文中の旧リンクについて、次を記録します。
HTTPとHTTPS以外が同じURLは、同じ記事の候補として扱います。ただし元URLは消さずに残します。
この章の目的は、単に画像ファイルを新サーバーへコピーすることではありません。
ココログにあった多数の画像表示形式を、WordPressで扱いやすい標準的な形へそろえることです。
ココログの複数の画像表示形式↓表示画像と原画像を特定↓画像をWordPressへコピー↓新しい画像URLを決定↓MTバックアップの画像HTMLを書き換え↓WordPressで扱いやすい単純なHTMLへ統一ココログでは、次のような記述が混在していました。
.shared/image.html?/window.open()class="mb"photos/uncategorizedblog/images_thumbこれらは削除する文字列の一覧ではありません。それぞれが、記事表示用画像、クリック先原画像、ココログ独自の画像表示機能などの役割を持っています。
ココログ側の複雑なHTMLを、基本的には次の形へそろえます。
<a href="新しい原画像URL"> <img src="新しい表示画像URL" alt=""></a><img src="...">：記事中に表示する画像<a href="...">：画像をクリックしたときに開く原画像alt：画像が表示できない場合などに使われる画像説明。元の値があれば残す表示画像と原画像を同じファイルへ統一する場合は、href と src が同じURLになります。
window.open と .shared/image.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>ここでは、
img src が記事中の表示画像href がココログ独自の画像表示ページonclick が別画面を開くための処理です。
.shared/image.html?/ はWordPress側には存在しないため、そのまま残すと、画像は表示されてもクリック時にリンク切れになる可能性があります。
<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>.shared/image.html?/ を使うココログ独自のリンクを残さないonclick を削除するhref を新しい原画像URLへ変更するsrc を新しい表示画像URLへ変更するclass="mb" があれば削除する<a href="http://buran.tea-nifty.com/photos/uncategorized/sample.jpg"> <img src="http://buran.tea-nifty.com/blog/images/sample.jpg" alt=""></a>この形式では、img src と a href の両方を修正します。
<a href="新しい原画像URL"> <img src="新しい表示画像URL" alt=""></a><a href="新しい原画像URL"> <img src="新しい原画像URL" alt=""></a>原画像が非常に大きい場合は、ページ表示が重くなる可能性があるため、少数記事で確認します。
class="mb"<a class="mb" href="旧URL"> <img src="旧画像URL" alt=""></a>class="mb" はココログ側の画像表示機能に関係する指定であり、WordPressではそのまま使う必要がありません。
<a href="新しい原画像URL"> <img src="新しい表示画像URL" alt=""></a>photos/uncategorized 直リンクhref と src が同じ画像を指している場合があります。
その場合は両方を新しい画像URLへ変更します。
<a href="新画像URL"> <img src="新画像URL" alt=""></a>_thumb 方式<a href="sample.jpg"> <img src="sample_thumb.jpg" alt=""></a>sample_thumb.jpg：記事表示用の小さい画像sample.jpg：クリック先の原画像この形式では2つの実ファイルを区別します。
<a href="新URL/sample.jpg"> <img src="新URL/sample_thumb.jpg" alt=""></a><a href="新URL/sample.jpg"> <img src="新URL/sample.jpg" alt=""></a><img src="旧画像URL" alt=""><img src="新画像URL" alt="">クリック先がないため、基本的には src の変更だけで対応できます。
file:/// 参照ココログ以外のサイトを参照する画像は、外部画像として別に扱います。権利や利用条件を確認せず、自分のサーバーへ自動コピーしない方が安全です。
file:///C:/...は、記事作成時のパソコン内ファイルを指していた可能性があります。旧パソコンやバックアップから元画像を探し、見つからなければ未発見として記録します。
例えば次の形で画像を集めます。
upload└─ 2016 └─ 09 └─ sample.jpgサーバー側の配置先は次のようになります。
wp-content/uploads/2016/09/sample.jpg同名ファイルは上書きしません。
sample.jpgsample-2.jpgsample-3.jpgファイル名を変更した場合は、画像対応表の配置先と新URLも更新します。
画像は、記事を本番で読み込む前にアップロードします。
画像対応表を完成↓アップロード用画像を作成↓WordPressサーバーへ画像を配置↓新画像URLをブラウザーで確認↓MTバックアップの画像HTMLを書き換え新URLを直接開き、画像が表示されることを確認します。
https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpgAIには次の処理を依頼します。
画像対応表を使い、MT形式バックアップ内の画像HTMLをWordPress向けの単純なHTMLへ変換するPythonプログラムを書いてください。
変換ルール:1. 記事表示用画像URLを対応する新URLへ変更2. クリック先URLを対応する新しい原画像URLへ変更3. .shared/image.html?/ を使う旧リンクを残さない4. onclick属性を削除5. class="mb"を削除6. border、hspace、vspaceなど古い表示指定を削除7. 元のalt属性があれば維持8. altがなければalt=""を付ける9. _thumbは対応表の指定に従って維持または原画像へ統一10. 外部画像は自動変換しない11. 未発見や複数候補は自動変換しない12. 可能ならHTML解析ライブラリを使い、タグの順番や改行の違いにも対応する
安全条件:・元のMTファイルは変更しない・変換結果は別ファイルへ保存・最初はdry-run・変換前後の例を出力・変換数、未変換数、エラー数を記録・最初の10記事だけでテスト可能・文字コードを維持記事本文には次のような過去記事リンクが残っています。
http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttps://buran.tea-nifty.com/blog/2008/03/post-abcd.html画像だけ移行しても、これらを直さなければ過去記事リンクは旧サイトへ飛びます。
実際の移行では次の方法を使いました。
WordPressへ記事を読み込む↓WordPressが実際に作った記事URLを取得↓旧URLと新URLの対応表を作成↓SQLを生成↓phpMyAdminで記事本文を一括更新↓Search Regexで旧リンクの残りを確認SQLはデータベースへ処理を指示する命令文、phpMyAdminはブラウザーからデータベースを操作する管理画面です。この方法は実施済みですが、初心者には難易度が高い方法です。
初心者向けには、WordPressのデータベースを直接変更せず、MTバックアップ側を先に直す方法を提案します。
MTバックアップから旧記事URLを抽出↓HTTrackでリンク先記事を特定↓記事タイトルと投稿日を取得↓新サイトの記事URLの付け方を決める↓旧URLと新URLの対応表を作る↓MTバックアップ内のリンクを書き換える↓WordPressへ少量テストで読み込むただし、この方法は全記事について実施済みではありません。少数記事でWordPressが想定どおりのURLを作ることを確認してください。
同じタイトルの記事が複数ある場合、タイトルだけでは新URLを決められません。
照合は次の順で行います。
タイトル＋投稿日＋投稿時刻タイトル＋投稿日投稿日＋本文冒頭表記ゆれを整えたタイトル手動確認oldurl_to_newurl.csvという名前で、次を記録します。
元の旧URLは消さずに残します。
OKと確認できたURLだけを変換します。
旧ココログ記事URL↓新WordPress記事URL記事本文で昔のURLを説明しているだけの箇所まで変えないよう、<a href="..."> のリンク先を優先して処理します。
旧URLと新URLの対応表を使い、MTバックアップの記事本文中にある旧ココログ記事リンクを新WordPress URLへ変換するPythonプログラムを書いてください。
条件:・元のMTバックアップは変更しない・結果は別ファイルへ保存・最初はdry-run・OKと確認済みのURLだけを変換・要確認、複数候補、未発見は変換しない・httpとhttpsの両方を確認・記事本文の説明用URLではなく、実際のリンク先を優先・変更した記事数とリンク数を記録・最初の10記事だけでテスト可能にする画像→ WordPressサーバーへ配置済み
新画像URL→ ブラウザーで表示確認済み
MT内の画像HTML→ WordPress向けの形へ変換済み
記事内の過去記事リンク→ 新URLへ変換済み、または未確定一覧へ分離済みhttp://buran.tea-nifty.comhttps://buran.tea-nifty.comburan.tea-nifty.com.sharedimage.htmlwindow.openclass="mb"photos/uncategorizedblog/imagesfile:///_thumb一致した箇所をすべて自動削除するのではなく、画像HTMLやリンクとして残っているのか、説明文に書かれているだけなのかを確認します。
テストには次を含めます。
.shared/image.html?/ を使う記事class="mb" を使う記事_thumb を使う記事10記事↓100記事または1か月分↓全記事の順で進めます。
変換済みMTバックアップを、MT形式に対応したWordPressの読み込み機能で取り込みます。
確認項目は次のとおりです。
問題があればWordPress上で大量に手修正せず、対応表と変換処理へ戻ります。
img src と a href の両方が新URLか.shared/image.html?/ が残っていないかfile:/// が残っていないかMTのimg srcとa hrefを確認↓個別記事HTMLを確認↓月別index.htmlを確認↓元画像名で検索↓.sharedフォルダーを確認↓更新日時を比較↓ファイルサイズと画像サイズを比較↓目視確認見つからない場合は、無理に別画像を割り当てず未発見として残します。
img src だけが新URLになり、a href が旧URLのまま残っている可能性があります。
サムネイルを原画像として使っている可能性があります。画像対応表の表示画像と原画像を確認します。
対応表を修正↓画像フォルダーを作り直す↓MTバックアップを変換し直す↓再検査↓再テストWordPress上だけを手修正すると、再読み込みしたときに同じ問題が復活します。
ココログからWordPressへの移行は、単にMTバックアップを読み込む作業ではありません。
旧サイトを保存↓記事・画像・旧URLの対応表を作成↓表示画像と原画像を特定↓画像をWordPressへ配置↓ココログの複数の画像表示形式をWordPress向けHTMLへ統一↓過去記事リンクを新サイト用に変換↓少量テスト↓本番移行↓旧URL、画像、クリック先、記事内リンクを検査画像移行の本質は、画像ファイルを集めることだけではありません。
ココログに混在していた複数の画像表示方式を理解し、表示画像と原画像を正しく特定し、img src と a href の両方をWordPress用の新URLへ直すことです。
そして、AIにすべてを勝手に判断させるのではなく、確定、要確認、複数候補、未発見を分けて記録することで、移行後の修正と再実行が可能になります。
0
PC関係 昨日の帽子画像、メキシカンハット、て言うそうなんですよ。
昔々、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