夢幻泡影 - 源本舗

趣味の日記

 
 銀英伝ボックス
2017年06月07日(Wed)
アニメ

20170607何気なくヤフオク見てたら『銀河英雄伝説』のLD-BOXセットが1000円で出品されており、思わず入札。
若干、競ったものの…格安で落札できました♪


…BDではなく、LDです(笑)
本伝×4セット、外伝×2セット、劇場版×3枚の、総計45枚。
劇場版のみボックスではないのが残念ですが、そこはそれ。
6穴バインダー式設定資料集、ノンテロップオープニング&エンディングVSD、そしてテレカと特典も全て付属します。(つか未開封状態)


銀英伝と言えば、本伝110話、外伝54話、長編3話という、OVAシリーズとしては空前、そして現時点では絶後である、言わずと知れた大作です。
出た当時、欲しくても高くて手が出せなかったこのLD-BOX。
なにせ、1セットで定価が税抜でも6万円から…という価格でしたからねぇ(涙)
話数の多い第3期なんて税抜87,378円。
本伝4セットだけで約28万円、トータルで約46万円という高価なものでした。


ぶっちゃけ、手元に全話のDVDがあるので、見る分には困らないものの…
やっぱ、このジャケットのサイズがいいのですよ♪
…場所とるけどw


今回、偶然見つけたとは言え、わざわざLDを入手したのは、この描き下ろしジャケットの魅力もありますが…
デジタル化の際に行われたリテイク前のソフトが欲しかったのが大きいです。
DVD化の際に、人名・艦名などのテロップのスペルミスなどが修正されましたが、同時に作画のひどかったシーンを中心にリテイクが行われました。
特にヤンをはじめとした主要人物の顔などが顕著ですが…
背景はそのままで、顔だけデジタル修正という形のため、肌の色などかなりの違和感があります(^^;
しかも作画デザインも外伝風のものとなっており、他の人物などとバランスがとれていない状態に。
さらに第1期のクライマックスである26話「さらば、遠き日」に至っては、背景まで含めてほとんど全て1から作り直しており、絵が変わりすぎて別のアニメを見ている様な有様です。


20170607b
26話より、LD(左)とDVD(右)の違いを比較
リテイクによって、雰囲気が全く別モノに…
全体的に絵柄が柔らかくなってますが… メックリンガー、可愛すぎw


確かに少なからず作画崩壊が見られた旧版ですが、昔のアニメとして考えれば問題無く見られるレベルかと。
26話なんてむしろ全体的にしっかりしたクォリティだったんだし、わざわざ作り直す必要なかったのでは?…というのが本音でしょうか。
全話を新たな作画で作り直すならまだいいんですが…
ごく部分的な修正のため、全体を通してのバランスがとれなくなっているんですよねぇ。


兎にも角にも、早速第7話「イゼルローン攻略!」までを一気見w
確かに時代は感じますが、やはり今見直しても面白いですね♪
新アニメプロジェクトについても、どういう形になるのか…楽しみなところです。


20170607a
LD画像をキャプチャで取り込み撮ったスクリーンショット
随所に見られるNTSC特有の色のにじみも味があってイイ感じです


ただ、LDプレーヤーの調子が悪くなってきているのか、ディスク終盤あたりになると横線状のノイズが入ることがありました。
特に異音などもありませんし、同期のズレっぽいので基板上の半抵抗を調節してやれば直ると思われますが…
無理して壊してしまってもシャレにならないですし、当面はこのまま放置でしょうか(^^;

名前  URL 

 

 
 XHTM1.0よりHTML5へ移行
2017年05月22日(Mon)
サイト

この日記ブログは自宅サーバ上の日記CGI「nicky!」にて稼働しており、XHTML1.0で出力される様にしていましたが…
ツイッターなど最近のブログパーツは、HTML5に対応するものがほとんど。
XHTMLの文法はかなり厳しく、ブログパーツなどの導入時はHTML5で追加されたタグや要素の所為で、ほぼ確実に文法上のエラーが出てしまいます。
ブラウザでの表示は問題無いことが多いものの、意図した様に表示されなかったりする場合も。


元々HTMLは文法にあいまいな点が多く、インターネットが普及してきた頃に主流だったHTML4.01ではブラウザによって見え方が違ったりと不都合も色々ありました。
その為、XHTMLは構造を厳密にしてブラウザでの互換性を高めることなどを目的として登場しました。
オイラもサイト制作を始めた当時、この互換性の高さ目当てでXHTMLをチョイスしたのですが…
実のトコロ…HTMLやXHTMLなどの規格を策定している「W3C」自体、次期規格となるはずだったXHTML2.0の策定を既に打ち切ってます。
結局、厳しい文法など融通の利かない部分が多いXHTMLへの移行はなかなか進まず、おまけにW3Cのゴリ押しへの反発などから、新たな団体「WHATWG」が設立されてHTML5が登場。
そしてHTML5が普及したことにより、XHTMLの不都合点もカバーできた上、その利点も減少。
結局、W3C自体もHTML5に注力しています。
XHTML5というのもあるけれど、XMLの機能拡張性にこだわらないなら、わざわざ選択する必要もなし。
結局、サイトのコーディングを見直す良い機会ということで、HTML5に切り替える事にしました。


まず、ヘッダに記述しているDOCTYPE宣言やhtml要素と文字のエンコーディング部分を変更。
基本的にはこれだけで、ブラウザからはHTML5のドキュメントとして扱われるようになるので、次は文法に沿って記述を直してゆきます。
nicky!の初期設定メニューから、XHTMLと設定していたタグモードをHTMLに戻します。
これで自動出力される、brやimgなどの空要素を閉じたタグはHTMLのものになりますが、ヘッダやフッタなどスキンの部分はそのままの為、「Markup Validation Service」を使用して、文法エラーを確認しながら手動で修正してゆきます。


問題は、CGIにより自動出力される部分。
カレンダーは追加CGI『minili.cgi』により生成されるのだけれど…
tableタグを用いており、これがまたHTML5になって廃止された属性である「align」「cellspacing」「cellpadding」などが多数使用されてたり。
これらは「style」属性でCSSに置き換える様、CGIを書き換えます。


■変更例

valign=\"top\"
 ↓
style=\"vertical-align:top;\"
 
cellpadding=\"0\" cellspacing=\"1\"
 ↓
style=\"padding:0; border-spacing:1;\"

その他、記事にジャンプするために使われていたaタグの「name」属性も廃止されているため、nicky.cgiを書き換えてXHTMLの時と同じspanタグと「id」属性を使うようにしました。


あと、記事中の埋め込み画像など幾つかの修正を加えたりして、Markup Validation Serviceで指摘されたエラーをつぶしてゆきますが…
最後に残ったのは…

Warning:
 Legacy encoding euc-jp used. Documents should use UTF-8.
 警告:古いエンコードのeuc-jpを使ってるね。
    ドキュメントはUTF-8を使わなきゃ駄目だよ。(意訳)


エラーではなく警告のため、必ずしも遵守しなければいけない訳ではないのですが…
これは流石にどうしようもないw
CGIによって出力されるテキストのエンコードを変更するには、Perlモジュール「Jcode.pm」を組み込んで文字コードを変換する、といった手段もあるようですが…
自分のスキルではそこまでの改造は無理。


なんだかんだで、nicky!も導入して13年が経過。
古いツールという事もあって利用者も減りつつある様で、改造しようにも情報が見つからないのが現状ですし…
本家も5年以上バージョンアップが止まっている残念な状況です。
まぁ、最近はブログサービスやSNSが広く普及したこともあり、CGI設置以前に自分でサイト制作する人自体が激減してるのが実情でしょうね。
思い切って、WordPressへ乗り換えるのもいいかもしれないなぁ。


>関連リンク
 DiaryCGI nicky!
 Markup Validation Service

名前  URL 

 

 
 スパムコメント対応
2017年05月05日(Fri)
サイト

日記ブログやってると、うっとうしいのがコメントスパム。
ウチみたいな弱小ブログでも、検索サイトでURLを拾ってくるのか、結構やってきます。
以前は中華系の偽ブランドについて怪しげな日本語で書き込みするものが多かったですが…
こういうのはツールやスクリプトなどによる自動書き込みが多く、名前にURL書いたりするので、書き込み禁止ワードを上手く設定することで回避することが可能。
実際、ほとんどの書き込みはフィルタで回避でき、たまに新たなパターンが出てきても、その商品名などを追加することで簡単に対応できていました。


しかし最近、半月に一回くらいのペースながら、10分間に20ものスパムコメントを連投してくる輩が。
毎回違うIPアドレスで、ご丁寧にブラウザまで別。
ただし、サイトそのもののアクセスログにはIPアドレスが記録されておらず、記事のURLに直接アクセスしている模様。
何らかのツールを使って、拾ってきたURLへプロキシやUser Agentを変えて自動書き込みしているのでしょうね。


現状、CGIをいじり、英語のみ(というか、1バイト文字オンリー)のコメントは書き込みできないようにしているものの…
残念ながらルーチンの都合上、書き込み通知メールは送信されてしまう。
スパムコメントの削除処理は不要なのだが、スマホへメールが届きまくるのは流石にウザい。


今回のスパムは北米のIPが中心で、言語設定も『en-us』。
閲覧して下さるユーザーを狭めることになるので、あまりやりたくは無かったのですが…
思い切って日本語以外のブラウザへアクセス制限をかけることにしました。
設定は至って簡単で『.htaccess』に下記を追記するだけ。


SetEnvIf Accept-Language "^[^(ja)]+$" no_jp
Order allow,deny
Allow from all
Deny from env=no_jp

ちなみにこれまでは、zh(中国語)、ko(韓国語)、ro(ロシア)…という様にスパムの多い国を個別に設定。
一応海外のSNSにも登録してたりするし、英語ならなんとか対応もできるので、フィルタはかけずにおいたのですけれどね…


しかしまぁ、Apacheのエラーログを見ると、定番とも言えるWordpressの『phpMyAdmin』へログインを試みるものなど、一日に数回は不正アクセスがあるもので(^^;
セキュリティ対策には気をつけているつもりですが、気を抜かないようにしたいものです。

名前  URL 

 

 
 oCのメイキングGIF出力の不具合
2017年04月19日(Wed)

20170419メインで使用しているグラフィックツールopenCanvas。
長らくバージョン4.5のままだったものを6にし、何年かぶりにお絵描きを再開したこともあって、放置していたpixivへの投稿を再開。
まずは、終了してしまったopenCanvas専用投稿サイト『ポタグラ』に置いていた過去絵の整理を始めました。(→こちら
2014年より「うごイラ」としてアニメーションGIFの投稿ができるようになっていたので、openCanvasならではの機能『メイキングGIF』出力を使用して、描画過程のアニメGIFも置くように。


なお、うごイラはアニメGIF形式でなくても、JPEGやPNGなどの静止画を複数枚投稿してアニメーション表示することも可能です。
投稿できる枚数の上限は150枚、1枚あたりの最大ファイルサイズは8MBまでとなっており、合計30MBまで。
アニメーションGIFを直接投稿する場合はファイルサイズの上限が8MB、500フレームまでの作品が投稿できます。
容量で考えると静止画像投稿が有利ですが、フレーム数で考えるとアニメーションGIFの方が有利ですね。
画像サイズについては、通常の画像ではピクセルサイズ30Mpxが上限(例:5,400×5,400)とされていますので、やはりこれに準拠しているのでしょうか。
一応、1920×1200ピクセルでのテスト投稿では問題無く動いてくれていますが…
画像サイズが大きくなると、当然ファイルサイズも増えてしまいます。
長辺を512ピクセルとして秒間4〜6フレームで30秒程度のアニメにするのが、上限の8MBに納めるのにちょうど良いくらいでしょうか。
再生時間が長すぎると、途中で飽きてしまいますし(苦笑)


ただ、openCanvasのメイキングGIF出力には現時点での最新版(ver.6.2.07)でもバグがある模様。
秒間コマ数や表示時間の設定によっては正常に再生されないGIFファイルが出力される場合が。
Windows標準のビューワ(フォトなど)やIEでは最後まで再生できても、Susieプラグイン系ビューワーやGoogle Chrome、Firefoxといった一般ツールでは途中で止まってしまう…というものです。
この状態だと、当然pixivやTwitterなどへ投稿しても受け付けてもらえず。
しかも、エラーとなる設定値は再生するイベントによってバラバラのため、何度か試してちゃんと再生されるものを用意しないといけません。
PC環境にもよるのかもしれませんが…
手持ちのPCは自作機とはいえ、Core i7 で Windows 10(64ビット)と極々普通の構成。
インストールされているソフト類を含めて、そんなに変わった環境ではないハズw


兎にも角にも、このままだと投稿用のGIFファイルを作るのに手間がかかるので、なんでかな〜と原因を色々と調べていたのですが…
アニメーションGIFエディタ『Giam』では、破損しているコマまで読み込んだところで「0x00は、未定義コードです」とのエラーがでて読み込みができませんでした。
バイナリエディタ『TSXBIN』にGIFファイルのシンボル表示を使用して該当箇所を確認したところ、Block Terminator (0x00) のあと、Extension Introducer (0x21) となるべきところで、再度 0x00 が。
これにより「未定義コード」としてエラーになり、ファイルの読み込みが止まってしまう事が判明。


20170419a
TSXBINのシンボル表示でエラーのあるファイルを表示
Block Terminator (0x00) が2回続いている


Extension Introducer (0x21) は、この 0x00 のすぐ後に続いており、データそのものが壊れている訳ではない模様。
1回でいいはずの Block Terminator (0x00) が2回連続して記述されている…という状態のようです。
この 0x00 の重複を削除して訂正することで、正常なアニメーションGIFとして再生ができるようになりました。


20170419b
修正後
続くデータも、きちんとシンボル表示される様に


幾つか正常に再生できないアニメーションGIFを用意して確認したところ、Graphic Control Extensionブロック(0x21 0xf9)の直前にのみ症状が現れる様子。
1回だけ重複が起こっているファイルもあれば、複数回現れる場合もありました。
いずれでも、ファイル内全ての2回連続している Block Terminator (0x00) のひとつを削除する事で症状は解消し、pixivやTwitterへも投稿できる様に。
一般的なビューワやブラウザは仕様通りでなければエラーとなるのに対して、Windows標準のビューワは、若干のエラーを許容して読めるみたいですね。


出力するプログラム内部の問題のため、原因まではわかりませんが…
症状を特定でき、その修正方法も判明したので、ひとまず公式に報告しておきました。
手動での修正も難しくは無いですが、出力されるファイルに問題無いのが一番ですから。
なにより折角のopenCanvasならではの独自機能ですし、利用者増加の為にも是非修正して欲しいところですね。


>関連リンク
 portalgraphics.net - openCanvas
 古溝 剛のオリジナルソフト公開ホームページ
 TSUCHYのホームページ
 W3C - GIF89a仕様書(テキストファイル)

名前  URL 

 

 
 桜の見頃もそろそろ…
2017年04月15日(Sat)
その他

20170415今年は例年より若干遅かったですが、無事に庭の桜も満開となりました。
ただ、天気の方はよろしくなく…
曇りか、強くはないものの雨が降る毎日。
8〜9日の土日には花見なども多くみられた様ですが、やはり雨がぱらついたりした為、屋内での飲み会…という感じだった様子。
結局、天気が良くなった頃には既に散り始めていましたね。


20170415a
市内の桜の名所
神社へ上がる階段には500本の桜の並木が


掲載の写真はいずれも満開だった時のもので、現時点ではそれなりに散り始め葉も見えて来てますが…
ソレはソレでなかなか。

名前  URL