昇華型プリンタでＯＨＰフィルムに印刷その４

今日も、インクカートリッジはお亡くなりになりましたorz
レーザープリンタ用ＯＨＰでも、やっぱりギリギリ鳴って、その上インクの載りも悪かったorz
パルコ株式会社のポリエステルタックフィルムとういのが、「昇華型熱転写プリンタでは、御使用になれません」という注意書きにもかかわらず、使ってみたら、とてもインクののりが良い!!
良すぎて、インクフィルムを引きちぎりましたwww
黄色はうまく、行くのですが、マゼンダでの引きちぎり率100%ｗｗｗ
3回印刷して、３回とも引きちぎった。
最初の２回は、繋がっている部分があったので、なんとか、手で巻いて復旧できたけど、３回目でとうとう完全に切断してしまった。
うーむ手が尽きたorz・・・
らくだ秋葉原店で、カラーレーザープリンタでの印刷ができるようだから、一度行ってみるか・・・
思いついたら、止まらない・・・

昇華型プリンタでＯＨＰフィルムに印刷その3

コーティング処理によって色が薄れる問題は、コーティング処理の直前でプリンタのコンセントを抜いて強制停止する事で解決したｗ
で、インクを買ってきたついでに、フリーラベルという、シールを買ってきた。帰って来てからググッたら再剥離タイプというのもあったが、買ってきたのは、がっちりくっつくタイプだった。剥がすために、シール剥離剤も買ったけど。
で、ＯＨＰシートに貼ってデジタルノギスで測ったら、なんと、純正用紙と同じ0.21mmだった。で、なんとなく硬さも同じぐらい。
「これは、成功する!!」という直感を持って、印刷しましたが・・・
失敗でした。
プリンタが、ギリギリ鳴って色むらが激しい。
手触りを確かめてみると、ＯＨＰはインクが載り易いように、少しざら付いている、のに対して、純正用紙はつるつる。
恐らく、インクフィルムと接触する時に、インクジェット用のＯＨＰは摩擦でフィルムを引っ張ってしまい、ギリギリ音が鳴り、また、余計な張力がかかっている為に、色むらが激しくなっているのだろう。
コーティング処理は、プリンタヘッドを洗う処理も兼ねているようだ、
コーティング処理をしないようにしてＯＨＰに印刷した後の数枚には、純正紙に印刷した時にドット欠けが見られるが、５枚目ぐらいからはそれが見られなくなる。
明日は、レーザープリンタ用のＯＨＰと手書き用ＯＨＰと再剥離なフリーラベルを買ってこようと思う。
金使いすぎ・・・orz

昇華型プリンタでＯＨＰフィルムに印刷その２

透明でないマスキングテープを貼って印刷できました。
ちなみに、透明なマスキングテープだと、「用紙がありません」エラーになりました。
で、いくつかわかった事、
最後の、コーティング処理で、どうも、色が落とされている。
そして、２度刷りをすると、インクフィルムが用紙に張り付いて、破れる
ええ、破れて、カートリッジは使い物にならなくなりました。orz
というわけで、今日の実験はこれで終わり。
カートリッジのインクフィルムを全部引き抜いてせめて、ＯＨＰ溶解用のダミーとして使えないかと、
試してみましたが、やっぱり、インク切れエラーが出ました。
多分、インクフィルムの黒線２本が用紙の区切り、一本が色の区切りとして認識しているのだと思います。
そのうち、分解して、インク無しでも動くようにしようｗｗｗ
また明日、新しいカートリッジを買ってきて挑戦する・・・と思う。

昇華型プリンタでＯＨＰフィルムに印刷

昇華型プリンタでＯＨＰフィルムに印刷する実験をしてみた。
結論から先に言うと、失敗した。
・凄く色が薄い
・色むらが激しい

考えられる原因として、
1.印刷する時に、フィルムが薄すぎて(約0.1mm厚)、次の用紙(約0.2mm厚)と一緒に流れて行った（ギリギリ音が鳴った他しｗ）。
　　・2枚流れる事で、滑ってしまった
　　・厚みが適正でないので、ヘッドがうまく動作しなかった
2.インクののりが悪い

対策
Ａ。厚み対策
１．約0.2mm厚のフィルムを探す
２．裏にマスキングテープを張って底上げする
３．フィルムを２枚張り合わせる
４．用紙を０．１ｍｍ削る（無理ｗ）
５．クリスタルレジン2等を使って作るｗ

Ｂ．インクののりが悪い対策
１．のりの良いフィルムを探す
２．のりが良くなるように何かコート剤をぬる

まぁ、実際の所、Ａの１，２、が駄目なら諦める

無圧縮でDotByDotで印刷するにはTIFFにしなくても、Ｂｉｔｍａｐで十分なようだ。

Boralnd C++BulderのTPrinterを使って
(PageWidth,PageHeight)を調べて見た所、
Ｌ版(89×119) 　 (1471,1100)=(1471*25.4/300,1100*25.4/300)=(124.54466666666666666666666666667, 93.133333333333333333333333333333)
ポストカード(100×148) (1823,1232)=(1823*25.4/300,1232*25.4/300)=(154.34733333333333333333333333333,104.30933333333333333333333333333)
カード(54×86) (1066, 669)=(1066*25.4/300, 669*25.4/300)=( 90.254666666666666666666666666667, 56.642)
ワイド(100×200) (2464,1232)=(2464*25.4/300,1232*25.4/300)=(208.61866666666666666666666666667 ,104.30933333333333333333333333333)
という結果になった。
Ｌ版で、1471ｘ1100のビットマップに１００ピクセル毎に線を引いて、1000この幅をノギスで測った所、約84.6になったので、端っこの方は切れるが、ビットマップでドットbyドットでいけそうだ。
次の実験ではいよいよ、ＯＨＰへの印刷に挑戦だ。

ＤＥＶＭＯＤＥから取って来た各種パラメータ
縁なしサイズ　縁有りサイズ 用紙サイズ 1ドット辺りのビット数
(1823,1232)　(1660,1121) (1000,1480) (260)
(1471,1100)　(1325, 991) ( 890,1190) (261)
(1066,669)　 (875, 577) ( 540,860) (262)
(2464,1232) (2241,1121) (1000,2000) (263)
「1ドット辺りのビット数」の値が何故か、変、普通、８ビットか２４ビットか３２ビットのはずなのだが・・・
ＯＨＰへの印刷さえ、できれば、視差バリアの手作りができる。

やっつけ仕事で修正

ソースを聞いて来ないなら、「強制的に聞いて来させる」という修正をした。
マシンによって

の表示が出るのと出ないのがあるので、
明示的に

を出すようにした。
つまり、VfwWrapper.cpp(25)に
　　DlgVideoSource();
を追加しただけ。
修正したＳＷのソース。
元のはもう消したけど。

ようやくできたと思ったら

ＶｉｓｔａとＸＰでどうやら、Video For Windowsの動作が違う事が判明。

Ｖｉｓｔａ(九十九のショップブランドのデスクトップ)：ドライバと接続した所で、どのカメラを使うかを聞いてくる。
ＸＰ(VAIO-TypeUX)：ドライバと接続した所で、適当にカメラに接続。

デバッグするのに、キーボードが打ちずれ～

ようやくできた。

ようやく、キャプチャーＳＷができた。
時々、Ｖｉｓｔａを撃墜してブルースクリーンになるし暴走もするけど（笑）。
シェアウェアは当然の事、フリーウェアとして公開するレベルには全然達していないが、
自分だけが実行する分には問題の無いレベルになった。
一時期は撃墜率５０％を誇っていたが、今では、油断すると撃墜する程度になった。
何度

この画面を見た事か、ウィルスバスターはちっとも悪くないんです。悪いのは全ては私のプログラムです。

そんな、デンジャーなＳＷのソースを見たいという方の為に、一応、公開しときます。
一応実行ファイルも入っていますが、実行は自己責任でお願いします。
VC++のデバッグモードでコンパイルした時とリリースモードでコンパイルした時の動作が違う等、まだまだ怪しいところはあります。
再配布等なんでも可にしているので、自分で書いていないコードの部分は付けていません。
ソースを見たり、実行したり再コンパイルしたい人はReadme.txtをよく読んどいて下さい。
Video For Windowsを使ったサンプルぐらいに思っておいた方が良いです。

愚痴解決

Video Fow Windowsをクラスでカプセル化していて、コールバック関数を
　　BOOL TVfwWrapper::SetCallbackOnVideoStream(TVideoStreamCbProc fpProc) {
　　　　return SndVFWMsg(WM_CAP_SET_CALLBACK_VIDEOSTREAM, 0,(LPARAM)(LPVOID)(fpProc));
　　}
ってな風に作っていました。
そして
　　typedef LRESULT (TVideoStreamCbProc)(HWND,VIDEOHDR　　static LRESULT VideoStreamCbProc(HWND hWnd,VIDEOHDR* lpVHdr) {
　　　　TVfwWrapper* pThis = (TVfwWrapper*)GetProp(hWnd,"ThisPoint");
　　　　return (pThis != NULL)? pThis->VideoStreamCallback(lpVHdr):(LRESULT)0;
　　}

としていたのを、
　　typedef LRESULT (CALLBACK *TVideoStreamCbProc)(HWND,VIDEOHDR*);
　　static LRESULT CALLBACK VideoStreamCbProc(HWND hWnd,VIDEOHDR* lpVHdr) {
　　　　TVfwWrapper* pThis = (TVfwWrapper*)GetProp(hWnd,"ThisPoint");
　　　　return (pThis != NULL)? pThis->VideoStreamCallback(lpVHdr):(LRESULT)0;
　　}

と、直したら、ちゃんと動くようになりました。

愚痴ってふて寝して目が覚めたら解決とは・・・。

この２週間はなんだったんだ（苦笑）。

愚痴

Cugwinのg++とVideo For Windowを使って、ステレオでキャプチャーするプログラムを作った。
1)開始→
２)　capGrabFrame()×２→
３)　　capFrameCallback()が２つ来るのを待つ→
４)　　　２つの画像のズレを計算する→
５)　　　　位置を合わせて推定左を赤でマスク、推定右をシアンでマスク→
6)　　　　 画像を表示する→
7)　　　　　　　２）へ戻る
をという物だったが、数フレーム/秒ぐらいしか出ない。
高速化するには、4)の処理をなんとかするべきなのだが、
画サイズを変えても大差が無いので、2)→3)の間が遅いようだった。
そこで、Captureデータを自動で投げて貰う為に、
capCaptureSequenceNoFile();
と、
capVideoStreamCallback()
で、取り込もうとしたが、１回目の
capVideoStreamCallback()
が終わった後に、「バンドルされていない例外が発生しました」になる。
「ファイルが無いのに書き込みに行っているのかな？」っとも思い、
capCaptureSequence();の方にして書き込むようにしてみるても、同じ。
分かった事は書き込んだ後に発生している事だけ。
どちらも、capVideoStreamCallback()を呼ばないようにすれば、正常に動作する。
VC++ Express
を入れて、どの辺りで例外が発生しているのか見ようとしたら、
capDriverConnect()で失敗するようになりやがる。
デバッガ有りだと失敗して、デバッガ無しだと成功する最低な状態。

プレビュー有りで、プレビューウィンドウがあると、
capCaptureSequenceNoFile()
で、
capFrameCallback()
が自動で来るが、何故か、プレビュウウィンドウが表示されていないと来ない。
これも、理由が分からない。が、まぁ、それはそういう仕様なのだろう。

う～っ頭いてぇ～