DecodeProto

O op extrai campos de uma mensagem de buffers de protocolo serializado em tensores.

Nota: Esta API foi projetada para ortogonalidade e não para ser amigável. Ele pode ser usado para analisar protos de entrada manualmente, mas destina-se ao uso em código gerado.

O op `decode_proto` extrai campos de uma mensagem de buffers de protocolo serializado em tensores. Os campos em `field_names` são decodificados e convertidos para os `output_types` correspondentes, se possível.

Um nome `message_type` deve ser fornecido para dar contexto aos nomes dos campos. O descritor de mensagem real pode ser pesquisado no pool de descritores vinculados ou em um nome de arquivo fornecido pelo chamador usando o atributo `descriptor_source`.

Cada tensor de saída é um tensor denso. Isso significa que ele é preenchido para conter o maior número de elementos repetidos vistos no minilote de entrada. (A forma também é preenchida por um para evitar dimensões de tamanho zero). As contagens de repetição reais para cada exemplo no minilote podem ser encontradas na saída `sizes`. Em muitos casos, a saída de `decode_proto` é alimentada imediatamente em tf.squeeze se os valores ausentes não forem uma preocupação. Ao usar tf.squeeze, sempre passe a dimensão squeeze explicitamente para evitar surpresas.

Na maioria das vezes, o mapeamento entre os tipos de campo Proto e os dtypes do TensorFlow é direto. No entanto, existem alguns casos especiais:

- Um campo proto que contém uma submensagem ou grupo só pode ser convertido em `DT_STRING` (a submensagem serializada). Isso é para reduzir a complexidade da API. A string resultante pode ser usada como entrada para outra instância do op decode_proto.

- O TensorFlow não tem suporte para inteiros não assinados. As operações representam os tipos uint64 como um `DT_INT64` com o mesmo padrão de bits de complemento de dois (o caminho óbvio). Valores int32 não assinados podem ser representados exatamente especificando o tipo `DT_INT64`, ou usando complemento de dois se o chamador especificar `DT_INT32` no atributo `output_types`.

- Campos `map` não são decodificados diretamente. Eles são tratados como campos `repetidos`, do tipo de entrada apropriado. O proto-compilador define os tipos de entrada para cada campo do mapa. O nome do tipo é o nome do campo, convertido em "CamelCase" com "Entry" anexado. A mensagem tf.train.Features.FeatureEntry é um exemplo de um desses tipos implícitos de `Entry`.

- Campos `enum` devem ser lidos como int32.

Ambas as serializações proto binárias e de texto são suportadas e podem ser escolhidas usando o atributo `format`.

O atributo `descriptor_source` seleciona a fonte dos descritores de protocolo a serem consultados ao pesquisar `message_type`. Isso pode ser:

- Uma string vazia ou "local://", caso em que os descritores de protocolo são criados para definições proto C++ (não Python) vinculadas ao binário.

- Um arquivo, neste caso os descritores de protocolo são criados a partir do arquivo, que deve conter um `FileDescriptorSet` serializado como uma string. NOTA: Você pode construir um arquivo `descriptor_source` usando as opções `--descriptor_set_out` e `--include_imports` para o compilador de protocolo `protoc`.

- Um "byte:// ", no qual os descritores de protocolo são criados a partir de ` `, que deve ser um `FileDescriptorSet` serializado como uma string.