IronOCRでは常に64ビットアーキテクチャを使用する
- # IronOCRでは常に64ビットアーキテクチャを使用する
IronOCRは膨大なメモリを消費する作業をバックグラウンドで行うため、32ビット（x86）ビルドでは約2GBのメモリ上限に達し、大きなドキュメントや大量のドキュメント処理で失敗し始めます。 64ビット（x64）をターゲットにすることで修正されます。
32ビットのプロセスは、マシンがどれだけのRAMを持っていても、約2GBの使用可能メモリに制限されます。 この制限を下回ると、OCR作業は通常以下のように示されます：
```txt
System.OutOfMemoryException
```
同じ上限による他の症状には、OCRエンジン実行中のデッドロック、画像前処理でのリソース不足、クラッシュや未処理例外、またはタイムアウトや静かに失敗するOCR結果があります。
圧力はIronOCRが1ドキュメントあたりに行う操作からきます：高解像度画像レンダリング、一時ラスタリゼーション、光学文字認識、`SearchablePDF`出力に使用される機械学習モデルでの深いテキスト抽出。 これらの各操作は、1ドキュメントあたり数百MBの要求をすることがあり、マルチページPDF、マルチページTIFF、300+DPIの画像ではそれ以上に増加します。
[[i:(IronOCRはOCR、画像レンダリング、およびPDFラスタリゼーション用にネイティブライブラリも呼び出します。 .NETガベージコレクタが確認できない管理されていないメモリを割り当てるため、32ビットプロセスでは更に圧力が加わります。)]]
## 解決策
### オプション1：Visual Studioでプラットフォームターゲットを設定する
ビルド設定を通じてプロジェクトをx64に切り替えます：
1. プロジェクトを右クリックして**プロパティ**を開きます。
2. **ビルド**タブを開きます。
3. **プラットフォームターゲット**を`x64`に設定します。
4. **32ビット優先**を外します。
### オプション2：CLIまたは.csprojからターゲットを設定する
64ビットランタイムに対して公開し、ビルド時にアーキテクチャを強制します：
```bash
dotnet publish -c Release -r win-x64
```
またはターゲットを`.csproj`に直接固定します：
```xml
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
```
プロジェクトが`<Prefer32Bit>false</Prefer32Bit>`の行が重要です：これが有効な場合でも、アプリは依然として32ビットプロセスとして起動し、同じ上限を引き継ぎます。
[[w:("32ビット優先"で"AnyCPU"を避けてください。 これは静かに2GBの制限を再導入し、64ビットマシン上でも同様です。)]]
## アーキテクチャを疑うとき
OCRジョブが予期せず停止したりクラッシュしたり、時折発生するメモリ不足例外、高ボリューム文書でのパフォーマンス低下が見られる場合、最初にアーキテクチャを確認してください。 x86で実行している場合は、他を調査する前にx64に切り替えます。
本番環境でいくつかの習慣を持続する：
- **本番用にx64をターゲット：**これは重いOCRワークロードに唯一サポートされている構成です。
- **x64で開発：** x64でのテストは現実のメモリ動作を反映し、初期段階で問題を発見します。
- **64ビットDockerイメージをビルド：**ベースイメージが`linux/amd64`であることを確認します。
並行OCR作業はメモリを急速に増加させます。小さな文書でも、マルチスレッドまたは非同期操作はすぐに上昇することがあります。
## アーキテクチャを変更できない場合
x64がオプションでない場合は、大規模な文書をより小さなチャンクに分割し、低解像度で処理します。 パフォーマンスと精度にトレードオフを期待してください。 32ビットプロジェクトの安定したサポートは現在調査中です。
Ask ChatGPT about this page
Ask Gemini about this page
Ask Perplexity about this page
IronOCRは膨大なメモリを消費する作業をバックグラウンドで行うため、32ビット（x86）ビルドでは約2GBのメモリ上限に達し、大きなドキュメントや大量のドキュメント処理で失敗し始めます。 64ビット（x64）をターゲットにすることで修正されます。
32ビットのプロセスは、マシンがどれだけのRAMを持っていても、約2GBの使用可能メモリに制限されます。 この制限を下回ると、OCR作業は通常以下のように示されます：
System.OutOfMemoryException
System.OutOfMemoryException
Text
同じ上限による他の症状には、OCRエンジン実行中のデッドロック、画像前処理でのリソース不足、クラッシュや未処理例外、またはタイムアウトや静かに失敗するOCR結果があります。
圧力はIronOCRが1ドキュメントあたりに行う操作からきます：高解像度画像レンダリング、一時ラスタリゼーション、光学文字認識、SearchablePDF出力に使用される機械学習モデルでの深いテキスト抽出。 これらの各操作は、1ドキュメントあたり数百MBの要求をすることがあり、マルチページPDF、マルチページTIFF、300+DPIの画像ではそれ以上に増加します。
IronOCRはOCR、画像レンダリング、およびPDFラスタリゼーション用にネイティブライブラリも呼び出します。 .NETガベージコレクタが確認できない管理されていないメモリを割り当てるため、32ビットプロセスでは更に圧力が加わります。
解決策
オプション1：Visual Studioでプラットフォームターゲットを設定する
ビルド設定を通じてプロジェクトをx64に切り替えます：
- プロジェクトを右クリックしてプロパティを開きます。
- ビルドタブを開きます。
- プラットフォームターゲットを
x64に設定します。
- 32ビット優先を外します。
オプション2：CLIまたは.csprojからターゲットを設定する
64ビットランタイムに対して公開し、ビルド時にアーキテクチャを強制します：
dotnet publish -c Release -r win-x64
dotnet publish -c Release -r win-x64
SHELL
またはターゲットを.csprojに直接固定します：
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
XML
プロジェクトが<Prefer32Bit>false</Prefer32Bit>の行が重要です：これが有効な場合でも、アプリは依然として32ビットプロセスとして起動し、同じ上限を引き継ぎます。
"32ビット優先"で"AnyCPU"を避けてください。 これは静かに2GBの制限を再導入し、64ビットマシン上でも同様です。
アーキテクチャを疑うとき
OCRジョブが予期せず停止したりクラッシュしたり、時折発生するメモリ不足例外、高ボリューム文書でのパフォーマンス低下が見られる場合、最初にアーキテクチャを確認してください。 x86で実行している場合は、他を調査する前にx64に切り替えます。
本番環境でいくつかの習慣を持続する：
- **本番用にx64をターゲット：**これは重いOCRワークロードに唯一サポートされている構成です。
- x64で開発： x64でのテストは現実のメモリ動作を反映し、初期段階で問題を発見します。
- **64ビットDockerイメージをビルド：**ベースイメージが
linux/amd64であることを確認します。
並行OCR作業はメモリを急速に増加させます。小さな文書でも、マルチスレッドまたは非同期操作はすぐに上昇することがあります。
アーキテクチャを変更できない場合
x64がオプションでない場合は、大規模な文書をより小さなチャンクに分割し、低解像度で処理します。 パフォーマンスと精度にトレードオフを期待してください。 32ビットプロジェクトの安定したサポートは現在調査中です。
テクニカルライター
Curtis Chauは、カールトン大学でコンピュータサイエンスの学士号を取得し、Node.js、TypeScript、JavaScript、およびReactに精通したフロントエンド開発を専門としています。直感的で美しいユーザーインターフェースを作成することに情熱を持ち、Curtisは現代のフレームワークを用いた開発や、構造の良い視覚的に魅力的なマニュアルの作成を楽しんでいます。
...
詳しく読む
