画像を途中までしか変換できない

1996年頃に作った30万枚以上の画像ファイルを，MacOS10.12.4でも見える様に4Dを使って変換しています。

当時のMacOS9でスキャナーで取り入れた画像をPICTで保存しており，これを外付けハードディスクを介して，今のMacにコピーしており，Mac標準のプレビューでも読み込むことが出来ます。

4D ver16-32bitで，$documentsにPICTファイルを入れ，
READ PICTURE FILE($documents;$picture)
CONVERT PICTURE($picture;".jpg";1)
WRITE PICTURE FILE($documents+".jpg";$picture)
DELETE DOCUMENT($documents)
を回して変換していますが，下の写真の様に上半分だけの画像になることがあります。元のPICT画像は全面が見えます。

憶測ですが，JPGではなく，PDFに変換するといかがでしょうか。

WRITE PICTURE FILE($documents+".pdf";$picture;".pdf")

注記：WRITEはCONVERTも兼ねているので，CONVERTは省略できると思います。

ありがとうございました。

".jpg"を".pdf"に換えると，うまく行きました。古い紙からのスキャン画像ですので，明るさを調整出来るフォーマットということで，JPEGを選んだのですが，必要がある画像はPDFを再変換してみます。

考えてみると，PICTはQuickDrawを使っているので，完全に変換出来なくても仕方ありませんね。ちなみにGraphicConverterでも同じ様な中途半端な画像になってしまいます。

Convert pictureが不要というのは言われてみれば納得です。

30万枚のPICTファイルの変換がほぼ終わりました。その際，気付いたことを。

変換先のフォーマットではなく，MacOSXでのPICTの読み込みに問題があったようです。

まとめて変換していたのですが，ファイルの枚数が多くなると，途中までしか変換出来ない上に，4Dがエラー表示なしに落ちる様になりました。MacOS9時代のPICTファイルですので，拡張子がなかったためのようで，ファイル名に.pictを付けると落ちなくなりましたが，途中までしか変換出来ない状態は完全に改善されませんでした。

これの対処の根本的な対策はまだ分からないのですが，再起動した直後に変換させるとうまくファイル全体が変換出来る場合があったので，およそ5000枚ずつ変換して行きました。そのまま次の5000枚を変換しても，大抵はうまく行かず，再起動と変換を繰り返しました。MacのROMにPICTを表示する機能はあるのでしょうが，何か少しの動作でそれらが使えなくなるのではと想像しました。

それとMacOS Classicを起動出来るマシンを捨てずに確保しておく必要があると考えました。MacOS9時代のファイルはマウント出来るのですが，ファイル名は文字化けします。MacOS Classic上でPICTファイルの変換をすることも最終手段として考えていましたが，そこまで行かずに作業を終えることが出来ました。

READ PICTURE FILEのドキュメント内で『それとなく』触れられていますが，画像ファイルの拡張子がなくても読めるかどうかは，macOSの『努力』に依存します。（「Windowsではファイル拡張子が必要です」と記述されています。）

http://doc.4d.com/4Dv16R2/4D/16-R2.1620/READ-PICTURE-FILE.301-3111821.ja.html

PICT/QuickDrawの場合，最初の数バイトが「ヒント」となりますが，これはQuickTimeだった場合，4Dの振る舞いが『再起動するまで』変わってしまうようです（経験上）。

具体的には，32ビット版で

SET DATABASE PARAMETER(QuickTime support;1)

を実行し，QuickTimeサポートを有効にしても，

QTファイルの変換に失敗すると，以後，再起動するまでQTファイルが変換できなくなるようです。

これを避けるためには，

まず

GET PICTURE FORMATS($PICT;$codecs)

でコーデックリストを調べ，".qif"が含まれていた場合，
PICTURE TO BLOB($PICT;$QIF;".qif")
BLOB TO PICTURE($QIF;$PICT)
でこれを『洗浄』します。

あとは，

PICTURE TO BLOBで任意の形式（PNGやPDF）に変換することができます。

32ビット版の場合，画像のようにサイズがバラバラなBLOBを連続的に読み込んでいると，キャッシュ内で断片化が発生し，空きスペースはあっても，連続した空きスペースが次第に不足してしまうかもしれません。

v16では，

FLUSH CACHE (*)

で一定サイズのキャッシュメモリを『奪還』することができるので，そうしたテクニックも場合によっては有効です。

http://doc.4d.com/4Dv16R2/4D/16-R2.1620/FLUSH-CACHE.301-3111248.ja.html

とはいえ，無事に変換を終えられて良かったですね・

本当にお世話になりました。

ストラクチャファイル，データファイルはv3.5で作っていたのですが，問題なく48個のデータファイルをv16まで変換出来，1個のストラクチャファイルの方も少しの修正で完動しましたし，自分で言うのもなんですが，見掛けも古くさくありません。

アドバイス頂いた変換の手順をここにも残しておきますと，
4D v3.5 → 4D 2003
4D 2003の4D Transporterを使い，Windows形式に変換
Windowsで4D 2004に変換
4D v11→v14→v16
一気に必死で変換したので，記録に残していないのですが，むしろ後半primary keyを作りますかという所で，まずって(だろうと思いますが，データが一致しませんと出ました)焦りましたが，何とか乗り越えられました。もう20年以上前になりますが，4Dを選んで正解でした。

フォームに画像を置いて，PDFで出力しようとしたのですが，画像がPICTからJPEGの変換の時の様に，途中までしか出力出来ませんでした。画像のみをWRITE PICTURE FILEで直接JPEGやPDFにすると欠けることなく出力出来ます。
PDFで出力出来るJPEGファイルと情報を比べてみるとかなり項目が少なく，PICTからの変換では足りない要素がある様です。