Photoshop のおかしな挙動

久しぶりにエロゲに関わることになったのだが、立ち絵を生成することになった。この立ち絵というのが、他のメーカーさんはどうしているのか知らないが、容量が増加傾向に有り、PSD ファイルでも 2GB を越えるような状況になってきた。
で、会社の開発機は Photoshop CC が入っていて、メモリは 16GB だった。
まぁ、メモリ 16GB もあるなら余裕だろうとかおもったら、これが全然動かない。スワップしに行ったまま、帰って来ない
なんじゃこりゃー!?
で、メモリの使用量を見てみると、これが半分くらいしか使われてない。
とにかくひたすら HDD(仮想メモリ)に書き込む。
いや、まだ 8GB 余ってるんだからそっち使えよ。

Photoshop のメモリ使用量とかいじっても挙動変わらず。さらに Photoshop が仮想記憶を作れないように色々と設定してみたが、ダメだった。

で、家に帰って作業の続きをしようと思い、立ち絵データを読み込んでみたが、これがまたすんなり動く。ちなみに家のマシンはまだ Photoshop CS4。と言うのも家のマシンはまだ Windows 7 なんだけど、Windows 8.1 にしようと思っていて、その時にアプリも全部新しくしようと思っていたのだが、なかなか Windows 8.1 にする気力も暇もなく、ずるずると何年も経ってしまっている。

今のところ結論からして Photoshop CC のメモリ管理が何か変わったのかなと。ただ自宅の開発機のメモリは 24GB、会社の開発機のメモリは 16GB という 8GB の差はあるんだけどね。

PDF とレモンジーナ

入稿を済ませた=電子書籍のデータも作れるんじゃないかということでやってみた。とりあえず PDF だけど。
で、思ったことが、いくら原稿がデジタルだからと言って、デジタルで入稿したんだから電子書籍もすぐだろっていうのは、そうでもないと感じた(笑)。ので、そういう考えはとりあえず捨てようと思う。

まず入稿データがすべて PDF で行われていたなら、たぶん電子書籍化も楽であろう。だが前回の日記のように、用意したのは一つのファイルではない。PDF は本文だけで、カバー、表紙、挿絵、口絵はすべて EPS である。
ただこれにはボク個人的な事情もある。そもそも PDF の画像データが信用できないのである。というのも 350DPI の可逆圧縮で本当に画像が収蔵されているのかどうかを確かめる方法が解らない。
Acrobat Reader で表示して拡大しても画像が荒れて表示されるのだ。
「果たしてこれ、ちゃんと印刷の時は 350DPI で出るんだろうか……?」
と、不安になってしまうのだ(汗)。
文字も絵も含めたすべての原稿を PDF で提出できれば、電子書籍のデータもそのまんま使えるだろう。

もう一つはデータの大きさである。ボク個人的には入稿したデータと同じデータで作りたいところだが、それで PDF を作ると 150MB くらいになった。すると LGA1366Core i7 マシンでも、挿絵や口絵にさしかかった瞬間、一瞬待たされる。
できればここはどのページも同じ速度でぱっと表示したい。でもあまり画像が劣化するのも嫌だ……などと思うと、どのくらいがいいのかあーでもないこーでもないと試行錯誤することに……(^^;
今のところまだ解決できていない。

更に問題になったのが、デバッグである。
果たしてちゃんとすべてのデータが問題なく吐かれているかどうかのチェックが、小説だとスゲーめんどくさい。これが薄い本だったら 24 ページとか、多くても 64 ページとか?
毎回生成するたびに、万一のことを考えて 268 ページチェックするのはかなり骨が折れる…orz

さて、最後にこの PDF データをどう配布するかで悩んでいる。なんか Amazon とかにも置けるらしいんだけどねー。
まぁそんなワケで、PDF にはしてあります。

写真は『レモンジーナ』。なんか会社の同僚が、これすごく売れてて品薄で、味も賛否両論別れているんだと言うので買ってみた。味は柑橘系の皮の部分のえぐみがちょっとあるけれど、まぁ普通に飲めた。
そして今日は 24 ℃だったようだ。

1506042289 1506042292 1506042294 1506042287

入稿してきた

OZ Meets OZ !』の原稿を入稿してきた。
FTP 入稿にしようかと思っていたのだが、この原稿で正しいか自信のないところもあったので、直接持っていくことにした。今回は行きは武蔵境通り(伏見通り→新武蔵境通り→武蔵境通り鶴川街道)→府中街道で行った。途中、どうも旧道らしきものと別れているところがあって、旧道に行ってしまった。
ただほとんど渋滞がなかった。

ねこのしっぽに着くと、お客は他に誰もいなかった(汗)。
なんか普段からいそうな気がするんだけど、アレかな、イベント前とかに殺到するのかもしれない。というのも、明らかに待つためのスペースなどがあるからだ。

データを渡して、その場でチェックしてもらう。データの内容は以下の通り。

  • カバー(1 枚、フルカラー、EPS
  • 表紙(1 枚、グレースケール、EPS)
  • 本文(266 ページ、グレースケール、PDF
  • 挿絵(2 枚、フルカラー、EPS)
  • 口絵(10 枚、グレースケール、EPS)
  • しおり(2 枚(表裏)、フルカラー、EPS)

やはり色々と不備はあった。
まず裁ち切り以外にも、文字など欠けては困るモノは裁ち切り線より 3mm ほど内側に寄せて欲しいとのことだった。栞の©表記や、人物相関図なんかがアウトだった。また、ページ番号にも少し考え方の違いがあった。
ボクの原稿は、原稿に打ってある頁数と、実際の紙の枚数ベースの頁数は違う。

表紙がページ 1、そしてその表紙の裏がページ 2、ページ 3 と ページ 4 にはフルカラーの挿絵が入っている。そのため 5 ページ目から本文が始まり、ページ番号はそこから 1 ページとして始まっている。
こうして紙に振られるページ番号と実際の紙の枚数はずれているのだが、ファイル名はすべて実際の紙の枚数に応じてつけていた。口絵と挿絵は DPI の確実性を確保するため PDF ではなく EPS ファイルとして別ファイルで用意していて、そのファイル名がページ番号になっているわけだが、それは物理的な紙の枚数でのページ番号をつけていたのだが、ねこのしっぽによると、紙に打ってある頁数に合わせてくれとのことだった。

あと中表紙というのだろうか、冒頭の出だしを書いたあとにタイトルのページがあるんだけど、そこのバックのグレースケールの絵がちゃんと出ないかもと言われた。あまりグレースケールの薄い灰色は期待しない方がいいらしい。
またそれと同じように、天音が着ている黒いゴスロリ服も陰影がほとんど解らないだろうとのことだった。
なかなか難しいなぁ。こう言うのはグレーズケールではなく 600DPI にして黒一色で作った方がいいのかもしれない。

指摘を受けたところはその場でノート PC で修正した。
簡単な修正だったので、ノート PC でも全然問題なかった。

なんだかんだで 1 時間以上かかった気がする。
まぁ何はともあれ、入稿は完了。あとは印刷ができあがるのを待つだけとなった。

さて、せっかくなので新丸子に来たのだから、何か食べようと言うことで新丸子駅前に行ってみる。油ソバの店があったので入ってみた……が、チェーン店じゃね?(汗)
しかもすた丼て……と思ったけど、ボクが知っているすた丼とは違うようだ。
どんなメニューにもミニすた丼が付いてくる(笑)。

で、食べてみたんだけど、味濃い。まぁ、当たり前か。若者の食べるものですな。
油ソバはまーこんなもんかって感じだったんだけど、すた丼がいただけない。不味いのである。おかしい、すた丼なんか美味しくしか作れないと思うんだけど。美味しいって言うか、要するに生姜 or ニンニク+甘辛い味付けでしょ。それさえしっかりしてれば誰でも美味しく感じるものが作れるはずなのに……。
店員の威勢はよかった(ぁ

1504022256 1504022258 1504022260

Twitter Card を設定してみる

Twitter で URL をつぶやいたとき、最近はその URL の概要が Twitter 上に表示されるのをちらほらと見るようになった。ボクのサイトを貼り付けても概要が表示されたりはしないので、何か仕掛けが必要なんだろうなと思っていた。
で、ちょっと検索してみると、それが Twitter Cards と言うものだというのを知った

で、ボクのサイトは WordPress というシステムを使っているので、おそらくこの Twitter Cards を自動的に設定してくれるプラグインがあるだろうとおもって探すと、あった。ボクが選んだのは Twitter Cards Meta というプラグイン。

設定自体はすぐに済んだ。
ただ一つ問題があって、ボクの日記は毎日その日の心情を表すキャラの表情が設定されている。Twitter Cards Meta ではその日の日記の一番最初に投稿されている画像を Twitter Cards の中に含めるようになっている。となるとどんな記事でも常にキャラの顔になってしまい、記事の内容とあまり関係なくなってしまう(^^;
そこでキャラの顔は WordPress にある「アイキャッチ」というのを使うことにした。
ただこれを使うとねぇ……記事のレイアウトがちょっと変わっちゃうのよねぇ。まぁ CSS と PHP いじれば何とかなると思うんだけど、何となく面倒なのでとりあえずはこれで行く(ぉ

さて、サイト側の設定はこれで済んだのだが、問題は Twitter に表示する方法である。え? 設定さえすればいいじゃないかって? どうもこの Twitter Cards を Twitter 上に表示するには Twitter に申請してウチのサイトも表示させてくださいと頼まないといけないらしいのだ。
が、公式サイトを探すも、特に申請する場所はない。
テストする場所はある。
一応、テストすると、ちゃんと表示される……ん~~~??

で、どうもこれはまだボクの予想でしかないのだが、前は申請しなくちゃいけなかったらしいが、テストして合格すれば OK っぽい?
とりあえず表示されるようにはなったので、これでいいであろう(ぇ

twitter_card

ねこのしっぽに行く

OZ Meets OZ !』の版下の準備がだいたい終わったので、実際に印刷屋さんに行って、版下を作る上で疑問に思ったことを質問しに行くことにした(ツイート)。いまのところ使う印刷屋は『ねこのしっぽ』さんである。
だがここのオンライン見積ではよく解らないこともあり、百聞は一見にしかずということでまずは行ってみることにしたのである。

場所は新丸子
正直縁がなく、どういったものか悩む。
環八から丸子橋渡ってすぐなんだけど、そもそも環八を通りたくない。が、たぶん R20 以南はおそらくあまり混んでいないだろうという希望的観測の元、東八道路に出て、それから吉祥寺通りで R20 に出、R20 から環八に入った。
なんだかんだで 1 時間 30 分かかった(ツイート)。
一時間で着きたかったなぁ。
1503142105

さらに問題なのが新丸子周辺の駐車事情である。実はねこのしっぽには以前ボクが関わっていたエロゲ会社の印刷物で来たことがあって、その時も駐車する場所に困った。というのもねこのしっぽは新丸子側からだと綱島街道を東側に渡った先にあるので、ボク個人的には綱島街道より東側に車を駐めたい。
ところがないのである。
まったく駐車場がないのである。
ねこのしっぽから一番近い駐車場は、おそらくねこのしっぽが面している商店街の道路にある駐車場なのだが、その商店街は 15 時から車両進入禁止になる。
新丸子駅の周囲には駐車場はたくさんあるんだけどね。
仕方がないので新丸子駅の近くのコインパーキングに駐め、そこから歩く。
写真は歩いてるときに見つけた、見たことないサイダー。サンガリアかぁ。
1503142118

ねこのしっぽでは、新書判と文庫サイズ(A6 判?)の大きさの違いやページ数の値段の違い、さらに本文は PDF でいいが、イラストは別ファイルの EPS でいいのか、などなど版下を作る上でいろいろ気になることを質問してきた。
さらに見積もりも出してもらう。
一番気になるのは新書判にするか、文庫サイズにするかっていうのとカバー付きにするかしないかの二点だった。
ちなみに予算は 7 万円である。
文庫サイズにすると 380 ページを突破してしまい、印刷代はカバー無しでも 10 万超えることが確定してしまった。新書判では 270 ページになり、カバー有りでも 7 万円におさまるらしい。
これは新書判かなー、と思いつつも、実は新書判にするには問題が一つあった。それは挿絵などのイラスト関係。ラノベと同じ装丁を考えていたので、縦横比を文庫サイズの方で作ってもらっているのよね。新書判は文庫サイズに較べて縦長になるので挿絵は左右が若干切れてしまうのだ。
まぁでもここは仕方ない、原画さんに切れる範囲を見せて許可をいただこうと、決めた。

さて、ねこのしっぽでの相談が終わって、今日は何も食べていなかったので地元の中華料理屋に入る。うん、無難。普通に食べられました。
1503142114 1503142116 1503142117

帰りは趣向を変えて、府中街道で帰ってきた。府中街道で矢野口まで出て、そこからひたすら武蔵境通りを北上。武蔵境通りはボクん家のわりと近くまで伸びているので、この帰り方だと 3 回しか交差点を曲がらないという(笑い。
でも所要時間は行きとあんまり変わらなかった……orz
下の写真は京王線の線路。何のことかって? 武蔵境通りと京王線が交差する地点で、かつては踏切だった。京王線が地下に潜って、今はもうその面影もだいぶない。まだ 1 年経ってないと思うんだけどなぁ。
1503142121

Sound Canvas for iOS

待ちに待った Roland Sound Canvas for iOS がリリースされた。こいつは Roland が発売していた GS 音源というシンセサイザを iOS 上で エミュレーションしてくれるソフトだ。ボクが過去に作った曲でも使われているシンセサイザーだ。
実はボクは SC-88Pro を二台所有していて、家に一台、会社に一台それぞれ置いてある。急にジングル作ってとか言われることがあるので、この SC-88Pro という音源でサクッと作ってたりしている。
ただいずれも古い機械で有り、いつ壊れてもおかしくない。
この iOS 版があれば、SC-88Pro が壊れても iPhone で再現できる。

と、思ってたんだけど……。

どうも iOS というか iPhone を PC から MIDI 音源として使うには色々と面倒そうだ。
Lightning ⇔ MIDI にするような装置が必要だ。そしてそれさえあれば PC 側から MIDI 信号を送ってやれば Sound Canvas for iOS がドライブできるのかどうかも、よくわからん。しかもその実験のために 12000 円も出すのもなぁ……。
あともう一つの問題が浮上した。それはその作った曲をどうやって録音するのかよく解らない。いや、そりゃヘッドフォン端子から音録ればできるけど、せっかくのエミュレータなのにデジタルのデータが欲しいよ? どうするんだろ。

さらに、普通に MIDI を再生するだけでも一苦労。Sound Canvas for iOS には MIDI ファイルを読み込んでそれを再生するいわゆるシーケンサも搭載されているものの、Roland から購入した MIDI ファイルしか再生できない。
iOS は Windows なんかと違って、アプリごとにアクセス出来る領域が決められていて、同じ iPhone 内にあるファイルを自由に読み込んだりすることはできない。ネットワーク上のファイルなんてもってのほか。Sound Canvas for iOS 専用の場所に MIDI ファイルを入れなければならないのだ。
うーむ、ボクのサーバには膨大な MIDI データがあるというのに……。

で、一応 Windows のエクスプローラみたいなソフトがあるんだけど、そいつを使うと無理矢理 Sound Canvas for iOS を外部から呼び出して MIDI ファイルが再生できることが解った。曲リストなどは作れないが、1 曲 1 曲ならこれでサーバ上の MIDI ファイルも再生できるようにはなった……が、今度はサーバ上の MIDI ファイルが ZIPLZH で固められていることだ(汗)。さらにそれらを展開しても RCP ファイルであることも多い……orz(当時のツイート
MIDI ファイルというか演奏情報って、けっこう繰り返しの塊だ。だからすごく圧縮が効く。数百 KiB のファイルが数 KiB になる。当時、HDD の容量が 100MB とかそういう時代だったので圧縮しておいていたのだ。
RCP ファイルってのは NEC の PC-98×1 に出ていたシーケンサ ソフトのファイル形式で、オリジナルの形式のため、今のソフトでは再生できない。当時は RCP がけっこう幅を利かせていたのだ。

と言うわけで、せっかく手に入れた Sound Canvas for iOS、今のところどう使ったらいいものか、困っている(笑)。
一番最後の写真は、自宅のシンセサイザたち。SC-88Pro は上から 4 つめ左の機械。

IMG_3315 IMG_3316 1506183320

 

溶岩焼ダイニング bonbori の打ち上げ

去年の 10 月から関わっていたソシャゲの打ち上げに呼ばれた。
場所は新宿の『溶岩焼ダイニング bonbori』というグリル料理屋。焼き肉屋のもうちょっと焼きに専門性を持たせたようなお店。
焼き物美味しい。
店員が焼いてくれるんだけど、面倒なので自分で焼いたりしてた(ぁ

打ち上げに呼ばれるのって久しぶりかも。
ボクはいつも複数のプロジェクトに関わっていて、あるプロジェクトが終わっても、他のプロジェクトで忙しかったり、打ち合わせが入っていたりして、打ち上げにはなかなか参加出来ないので、なんだか嬉しい。

腹一杯食べてしまった。

一番最後の写真はチーズではなくてフォアグラ。

1502241461 1502241463 1502241464 1502241466 1502241469