それ以外の意味は何もありません。画像かどうかなど知ったことではないんです。パスを認識せずファイルとして特定できなくなります。FileMakerが対応していない画像タイプだからです。FileMakerが対応していない画像タイプは、FileMakerにとって画像ではありません。画像かどうかではなく、FileMakerが対応しているかどうかが優先されます。FileMakerが扱うパスは、パス情報をオマケに持つものの、根幹はFileMaker事情のミクロ的な分類データであると言えます。種類と目的+パスがセットになったFileMakerのパスは、普通のパスのように使えません。目的に応じて使い分けたり作り分ける必要があったんです。作るパスは常に接頭語付きのパスですから、それをパスとして特殊な用途、例えばリレーションの「照合」に使ったりしたら、いろいろ不整合が起きてしまいます。テーブルをまたいだときに「image:」だの「imagemac:」だのとそれぞれバラバラだったら照合もくそもありませんし。フォルダインポートで更新するときに「ファイルパス」を照合フィールドに指定してもまったく照合なんかしてくれません。以前リレーション用に接頭語を取っ払った「パスモドキ」フィールドを作りましたが、あれこそ正しいやり方でした。正しくありませんでした。種類+パスGetAsTextで取得する分類情報にパスがくっついたもの。FileMakerで取得できるパスの形。FileMakerの都合による勝手な分類がなされて接頭語として付与されます。普通のパスが欲しい場合、接頭語以降のパス部分を利用します。インポート元パスフォルダ一括インポートでアイテムを取得するときに「ファイルパス」と示され取得できるパス。実態は、その時点でどのファイルをインポートしたかの記録にすぎません。長年これを勘違いして「パス」であると思い込んだことが多くの悲劇を生みました。」で、この書式は厳密にはFileMakerのパスですらありません。パスとして認識されず何にも変換できません。」は、パスの体をなしていない単なるメモ書きと思っておくのが正解でした。以降を抽出するともちろんパスです。パスと異なってくる可能性がありますよね。インポート元パスとGetAsTextパスは一緒くたにしてはいけなかったのに、それをやってドツボにハマったというのが私の愚かなところでした。FileMakerで取得できるパスのようなものは上記二点。取得できるパスを元に、パスフィールドのバリエーションを作ることになります。必要パスフィールドインポート元パスそんなわけで、これまで「ファイルパス」というフィールド名だったのですが、これを即刻やめて、「インポート元パス」「オリジナルのパス」みたいな名前に替えます。フォルダインポートをしていないレコードではこのフィールドは空のままです。これまで阿呆の私は、空である場合にはGetAsTextからパスを生成して同フィールドに記入していました。「file://」を別の(パスとして認識できる)接頭語に勝手に変換したりしていました。そのせいで照合もできなくなり混乱に陥りました。インポート時に得られるパス情報のメモ書きフィールドは、基本的にそのままの形で温存しておくのが正しい対処です。」以降だけを抽出します。これは厳密にはパスではないですが、接頭語を取っ払ったパスフィールドを確保することで、利用に応じて接頭語を付け足したり、他形式に変換したり、あるいは純粋位置情報として、リレーションの照合フィールドにも使えます。変換されたパスフィールド環境に応じたパスのフィールドをこしらえます。MacならPOSIXです。AppleScriptやターミナルにコマンドを送る際、常に必須なPOSIXは、V19の関数を使ってもいいし、substituteで自作関数を作っておいても良いと思います。フォルダやや細かな話になりますが、フォルダ以下のファイル群を一括で処理したいことが多いので、ファイル名を除いたフォルダまでのパスフィールドを作っておくことも役に立ちます。いうことで実作編を作り直したほんと我ながらド素人ぶりに呆れますが、このような基礎的な知見を30年も使ってきて初めて知ったということで、ですのでこれまでの実作編を作り直しました。記事も多く改変します。その後、実作編を全部リセットして最初からまた始めました。唐突に無関係な個人的日記を書きますが、このブログの画像にも時々登場する猫、とめが2021年8月7日に死んでしまいました。22年間人生を共にしてきまして大往生の筈なのですが、喪失のダメージ大きすぎてしばらく立ち直れそうにありません。