DecodeProto

この操作は、シリアル化されたプロトコル バッファー メッセージからフィールドをテンソルに抽出します。

注: この API は、人間に優しいというよりも、直交性を重視して設計されています。これは入力プロトを手動で解析するために使用できますが、生成されたコードで使用することを目的としています。

`decode_proto` オペレーションは、シリアル化されたプロトコル バッファー メッセージからフィールドをテンソルに抽出します。 `field_names` 内のフィールドはデコードされ、可能であれば対応する `output_types` に変換されます。

フィールド名のコンテキストを提供するには、`message_type` 名を指定する必要があります。実際のメッセージ記述子は、リンクされた記述子プール内で検索することも、呼び出し元が「descriptor_source」属性を使用して指定したファイル名で検索することもできます。

各出力テンソルは高密度テンソルです。これは、入力ミニバッチ内で見られる最大数の繰り返し要素を保持するためにパディングされることを意味します。 (サイズがゼロになるのを防ぐために、形状にも 1 が埋め込まれます)。ミニバッチ内の各サンプルの実際の繰り返し数は、「sizes」出力で確認できます。多くの場合、欠損値が問題にならない場合、「decode_proto」の出力はすぐに tf.squeeze に入力されます。 tf.squeeze を使用する場合は、予期せぬ事態を避けるために、常にスクイーズ ディメンションを明示的に渡します。

ほとんどの場合、Proto フィールド タイプと TensorFlow dtype の間のマッピングは簡単です。ただし、いくつかの特殊なケースがあります。

- サブメッセージまたはグループを含むプロト フィールドは、`DT_STRING` (シリアル化されたサブメッセージ) にのみ変換できます。これは、API の複雑さを軽減するためです。結果の文字列は、decode_proto 演算の別のインスタンスへの入力として使用できます。

- TensorFlow は符号なし整数をサポートしていません。 ops は、同じ 2 の補数ビット パターンを持つ `DT_INT64` として uint64 型を表します (明白な方法です)。符号なし int32 値は、型 `DT_INT64` を指定するか、呼び出し側が `output_types` 属性で `DT_INT32` を指定する場合は 2 の補数を使用することによって正確に表現できます。

- `map` フィールドは直接デコードされません。これらは、適切なエントリ タイプの「繰り返し」フィールドとして扱われます。プロトコンパイラは、各マップ フィールドのエントリ タイプを定義します。 type-name はフィールド名を「CamelCase」に変換し、「Entry」を付加したものです。 tf.train.Features.FeatureEntryメッセージは、これらの暗黙的な `Entry` タイプの 1 つの例です。

- `enum` フィールドは int32 として読み取られる必要があります。

バイナリとテキストの両方のプロトシリアル化がサポートされており、`format` 属性を使用して選択できます。

`descriptor_source` 属性は、`message_type` を検索するときに参照するプロトコル記述子のソースを選択します。これは次のようなものかもしれません:

- 空の文字列または「local://」。この場合、バイナリにリンクされた C++ (Python ではない) プロト定義用のプロトコル記述子が作成されます。

- ファイル。この場合、プロトコル記述子はファイルから作成され、文字列としてシリアル化された `FileDescriptorSet` が含まれることが期待されます。注: プロトコル コンパイラ `protoc` の `--descriptor_set_out` および `--include_imports` オプションを使用して、`descriptor_source` ファイルを構築できます。

- 「バイト://」 "、プロトコル記述子は ` から作成されます`、これは文字列としてシリアル化された `FileDescriptorSet` であることが期待されます。