サイズが4GBを超える画像を読み込もうとすると、例外をスローする画像操作ライブラリを使用しています。64ビットであると主張していますが、64ビットライブラリではそれより大きい画像をロードできませんか？彼らは64ビットメモリモデル/コンパイラを使用してCライブラリを再コンパイルしたと思いますが、それでも符号なし整数を使用し、64ビットタイプを使用するようにアップグレードできませんでした。
それは合理的な結論ですか？
編集-後から考えると、OSメモリが非常に断片化されて、大きなチャンクを割り当てることができなくなる可能性がありますか？（再起動直後も機能しませんが、疑問に思っています。）.NETではどうでしょうか。.NET管理対象メモリが断片化されて、大きなチャンクの割り当てが失敗する可能性はありますか？
これは合理的な提案ですが、正確な原因はさまざまなものである可能性があります。たとえば、実行しているOS、RAM/スワップの量などです。アプリケーション/OSは仮想メモリをオーバーコミットしない可能性があるため、イメージを開くには4GB（またはそれ以上）の空きRAMが必要です。
興味深いことに、4GBの境界で確実に停止しているように見えます。つまり、3.99GBのイメージは成功しますが、4GBのイメージは失敗します。これは、ライブラリのデータ構造で32ビットサイズを明確に使用することを示唆していると言えます。
アップデート
あなたの2番目の質問に関して-実際にはそうではありません。最近のほとんどすべてのOSは仮想メモリを使用しているため、各プロセスは独自の連続したアドレス空間を取得します。プロセスのアドレス空間内の単一の連続した領域は、連続した物理RAMでバックアップする必要はありません。連続しているように見せるために、RAMの複数の個別の物理領域で構成できます。したがって、アプリケーションに4GBのチャンクを提供するために、OSに4GBのRAMのチャンクを1つ空ける必要はありません。
アプリケーションが仮想アドレス空間を断片化して、連続する4GBリージョン用のスペースがない可能性がありますが、64ビットアドレス空間のサイズを考慮すると、シナリオではほとんどあり得ません。
はい、おそらくバイナリファイル形式自体が画像のサイズを制限しない限り。