による連番ファイル出力の画像形式はPSDのみだった。１枚１枚ならTIF,PNG,BMP,TARGAと多彩だけど連番は何故かPSD固定。
…まぁいいけど。確かに何か一つ、と言われればPSD。
あと、mdpsファイル内に定義されてるmdpファイルとファイル名の対応は無く、連番になる。そりゃそうか。

が出てきたので使ってみる。発熱はするんだが２時間位で冷えてしまう。
まぁ通勤途中だけ使えれば使命は果たせるのでのこり９個も使おう。
早く使いきらないと春になってまた１年眠らせる事になってしまう。

identify A01.tif
A01.tif[0] TIFF 8688x6168 8688x6168+0+0 1-bit Bilevel Gray 1.874MB 0.000u 0:00.000
A01.tif[1] TIFF 160x113 160x113+0+0 8-bit sRGB 1.874MB 0.000u 0:00.000

白黒1bitで大体2MBか。昨日の調査によるとやっぱ今回は一旦PNGにしてそれを
mogrify -type Grayscale -compress LZW -format tif *.png
でTIFFにするしか方法が無いか。
そういえば何故かあの時のTIFFにはサムネイルが付いてた。多分PSDを入力にしたからだろうな。ComicWorksからの書き出しも余計なものが入らないPNGが安全だろう。PNG→PNG→TIFF。

最終的に出力される画像の色数や圧縮形式が、バージョンやQ16/Q8、アロケート時にxc:noneかxc:whiteか、入力画像の色数、透明度の有無、出力形式がTIFFかPNGか、で変わって明示的に指定出来ぬ。
欲しいのは２値のTIFFなんだけど、今のところわかった生成ルートは以下の通り。本当はmogrifyは使わずJMagickで完結させたかったんだが良く判らぬしもうこれでいいわ。
・ImageMagicのバージョンは6.8.3 Q8を使用。
・アロケート時には白のxc:whiteを指定。xc:noneだと透明。透明部分があると挙動が変わる。
・入力ファイルに透明度が付いていてもいなくても良いように、CompositeのオペレーションはCopyではなくDarkを使う。Copyすると入力ファイルが透明度ありだと透明度もコピーされてしまうので。意外に速度は変わらず。
・出力形式がPNGの場合は、256色グレイスケールパレットなPNGとなる。
・出力形式がTIFFの場合は、32bit透明度ありのフルカラーなTIFFとなる。何も指定しないと無圧縮なので200MB。事前にImageInfoのCompressにLZWを指定すると小さくなるがこの場合、Windowsのビューワでは見えず、Paintgraphic2 Proやデリーター コミックワークスNEOで読もうとすると落ちる。
・上記で作成したPNGを mogrify -type Grayscale -compress LZW -format tif *.png で変換すると白黒２値LZW圧縮TIFFとなる。これは普通のツールでも読める。
・またJMagickで作った妙なフルカラーLZW圧縮TIFFを mogrify -type Grayscale -compress LZW -format tif *.png で変換するとグレイスケールLZW圧縮TIFFとなる。これは普通のツールでも読める。
　ちなみにJMagickでPNGを出力するのとTIFFを出力するのでは掛かる時間が４０秒近く異なる。TIFFの方が速い。色数も違うしJMagickというかImageMagickの挙動は訳判らないな。
　JavaFXでのGUIの皮だけは出来てるし、面付けは以前のプログラムと同じアルゴリズムでＯＫだから、JMagickがスレッドセーフか否か以外は大体要素技術はクリアになった感じ。CPU使用率を見るとコア数+1位が良さげ。後はヨーカドーのコニカミノルタ bizhub C353CSで印刷テストして形式を決める。

最近は治まっていたんだけど、土曜あたりから今度は左胸がじわじわと痛む。骨がズキズキでは無いので割と平気。

　んで、目下の課題は、いかにして２値モノクロLZW圧縮TIFFを出力させるか、である。イトーヨーカドーのコピー機はPDF,JPG,TIFFしか受け付けないのだ。まぁ最悪、PNGで出力して最後に

mogrify -type Grayscale -compress LZW -format TIF *.png

で一括変換という技もあるにはあるが無駄な時間だし。ちなみに今、JMagicからTIFFを吐くと無圧縮フルカラー32bitの200MBのファイルとなる。
昔のMLにそれっぽい話を発見
http://permalink.gmane.org/gmane.comp.java.jmagick/842

i'm using jmagick 6.0.4 and trying to create a image with the following  
properties:
-colorspace GRAY -normalize -gamma 1.4 -compress LZW -mime tif

here`the code:

     ImageInfo imageInfo = new  ImageInfo("D:\\imageprocessing_js\\sonnenuntergang.jpg");

     MagickImage image = new MagickImage(imageInfo);

     image.setFileName("D:\\imageprocessing\\sonnenuntergang.jpg");
     imageInfo.setColorspace(ColorspaceType.GRAYColorspace);
     image.normalizeImage();
     image.gammaImage("1.4");
     image.setMagick("TIFF");

     byte[] blob = image.imageToBlob(imageInfo);

     image.blobToImage(imageInfo, blob);
     image.setCompression(CompressionType.LZWCompression);
     imageInfo.setCompression(CompressionType.LZWCompression);
     image.setImageAttribute("compression","LZW");
     image.setFileName("D:\\imageprocessing\\newimage.tif");
     image.writeImage(imageInfo);

これだけあちこち指定してもLZW圧縮かからないそうな。リプライ無いし。
まぁさすがに６年後の今の最新版なら直ってるだろうと

    imageInfo.setCompression(CompressionType.LZWCompression);

にあたる処理だけ実装して実行したら、なにやら小さめのTIFFが出た。が、大きさから判断してこれはまだフルカラーだ。
しかもWindows XPのプレビューは表示できず、Paintgraphic2 Proで読み込むと落ちる。

　今までは6.3.9-Q16を使っていて５分掛かっていたが、手順をちょっと変えてとどめに6.3.9-Q8を使うように変更したところ15秒になった。調子に乗って最新版の6.8.3-1-Q8にしたところ60秒と遅くなった。*1その後更に手を入れて40秒に。
　ただし、同一処理後に吐き出すPNGが6.3.9では無駄にフルカラーなのに対して、6.8.3-1では正しく2値なのでここは最新版の方を使う事とする。バグとかも減ってるだろうし。遅いのはおそらく内部の8bitデータをそのまま吐かずに1bitにパックしてるから。
　挙動を見たところ、どうも画像のロードやアロケートを、APIで呼び出した時にその場では行わず、実際に使う時になってから確保するっぽい。全体処理が遅い割にはロードやアロケートAPIからの戻りが異常に速いし、読み込んだ画像の情報をトレースに出すのをやめただけで処理が先に進むのが速くなったし。あと遅延ロードのような事もしているのか、左記の情報出力でのブロックを止めると全体の処理時間が１０秒も縮まった。１枚読んでは情報出力、もう１枚読んでは情報出力、その後実際の合成処理とシリアルに動いてた所が一部同時実行されたのではなかろうか。
　それにしてもバージョン変えると挙動が変わるのは困りもの。コマンドラインのオプションも統一感無いし何でこんなへんてこなImageMagickがメジャーなんだろうと思ったりもするけど、マクロ機能付きのGUIツールは色々あれど、コマンドライン主体の画像処理ソフトって他に無いからかな。特にLinux。

前も調べたけど忘れるのでWeb日記に記載
※以下はすべて600dpi前提

原稿用紙全体サイズは4961×7039
Ａの位置は(330,485)、Ｂの位置は(4069,6555)。
Ａ３横サイズは9922 × 7016
Ｂ４横サイズは8588 × 6071
つまり
Ａ３版下作るには、左ページは右端330ピクセル、上12ピクセル、下12ピクセルをカット、右ページは左端330ピクセル、上12ピクセル、下12ピクセルをカットして、二つを中央で張り合わせる。左右が３３０ピクセル分不足だが、印刷時に中央あわせでＯＫ．
Ｂ４版下作るには、上記の処理であわせた画像を左右662ピクセル、上下484ピクセルカット。
※JMagickの場合は、cropした画像も原点はcrop前を保持するので注意。
※出力装置によっては用紙一杯の大きさのデータは印刷範囲を超えるので勝手に縮小してモアレる事があるので、上下左右をさらにカットする方が良いかも知れない。