DecodeProto

Операция извлекает поля из сериализованного сообщения буфера протокола в тензоры.

Примечание. Этот API разработан с учетом ортогональности, а не удобства для человека. Его можно использовать для анализа входных прототипов вручную, но он предназначен для использования в сгенерированном коде.

Операция `decode_proto` извлекает поля из сериализованного сообщения буфера протокола в тензоры. Поля в `field_names` декодируются и преобразуются в соответствующие `output_types`, если это возможно.

Необходимо указать имя message_type, чтобы указать контекст для имен полей. Действительный дескриптор сообщения можно найти либо в пуле связанных дескрипторов, либо по имени файла, предоставленному вызывающей стороной, с использованием атрибута `descriptor_source`.

Каждый выходной тензор является плотным тензором. Это означает, что он дополняется так, чтобы содержать наибольшее количество повторяющихся элементов, наблюдаемых во входном мини-пакете. (Форма также дополняется единицей, чтобы предотвратить нулевые размеры). Фактическое количество повторений для каждого примера в мини-пакете можно найти в выводе «размеры». Во многих случаях выходные данные `decode_proto` немедленно передаются в tf.squeeze, если пропущенные значения не вызывают беспокойства. При использовании tf.squeeze всегда передавайте измерение сжатия явно, чтобы избежать сюрпризов.

По большей части сопоставление между типами полей Proto и типами TensorFlow является простым. Однако есть несколько особых случаев:

- Поле прототипа, содержащее подсообщение или группу, может быть преобразовано только в `DT_STRING` (сериализованное подсообщение). Это сделано для уменьшения сложности API. Полученную строку можно использовать в качестве входных данных для другого экземпляра операции decode_proto.

— В TensorFlow отсутствует поддержка целых чисел без знака. Операции представляют типы uint64 как `DT_INT64` с тем же битовым шаблоном с двоичным дополнением (очевидным способом). Беззнаковые значения int32 можно представить точно, указав тип `DT_INT64` или используя дополнение до двух, если вызывающая сторона указывает `DT_INT32` в атрибуте `output_types`.

- Поля `map` не декодируются напрямую. Они рассматриваются как «повторяющиеся» поля соответствующего типа записи. Протокомпилятор определяет типы записей для каждого поля карты. Имя типа — это имя поля, преобразованное в «CamelCase» с добавленным «Entry». Сообщение tf.train.Features.FeatureEntry является примером одного из этих неявных типов Entry.

- Поля enum следует читать как int32.

Поддерживаются как двоичные, так и текстовые сериализации прототипов, их можно выбрать с помощью атрибута format.

Атрибут `descriptor_source` выбирает источник дескрипторов протокола, к которым необходимо обращаться при поиске `message_type`. Это может быть:

— Пустая строка или «local://», в этом случае дескрипторы протокола создаются для определений прототипа C++ (не Python), связанных с двоичным файлом.

- Файл, в этом случае дескрипторы протокола создаются из файла, который, как ожидается, будет содержать FileDescriptorSet, сериализованный в виде строки. ПРИМЕЧАНИЕ. Вы можете создать файл `descriptor_source`, используя опции `--descriptor_set_out` и `--include_imports` для компилятора протокола `protoc`.

- "байт:// ", в котором дескрипторы протоколов создаются из ` `, который, как ожидается, будет `FileDescriptorSet`, сериализованным в виде строки.