Recursos de imagem#
Algumas características mencionadas estão intrinsecamente ligadas aos serviços que utilizam o recurso de imagem. Esses serviços são os seguintes:
Extensões de arquivos suportadas#
São suportados pela API os seguintes tipos de arquivo:Tipo de Documento | Extensão do Arquivo | MIME Type |
---|
AVIF | .avif | image/avif |
BMP | .bmp | image/bmp |
Graphics Interchange Format | .gif | image/gif |
HEIC | .heic | image/heic |
Joint Photographics Experts Group | .jpeg | image/jpeg |
JPEG 2000 | .jp2 | image/jp2 |
JPEG File Interchange Format | .jfif | image/.jfif |
JPG | .jpg | image/jpeg |
JXL | .jxl | image/jxl |
PAM | .pam | image/x-portable-arbitrarymap |
PBM | .pbm | image/x-portable-bitmap |
Portable Document Format | .pdf | application/pdf |
Portable Gray Map | .pgm | image/x-portable-graymap |
Portable Network Graphics | .png | image/png |
Portable Pixmap Format | .ppm | image/x-portable-pixmap |
Tagged Image File Format * | .tiff | image/tiff |
WEBP | .webp | image/webp |
Para arquivos TIFF que possuam mais de uma página, a extração ocorrerá apenas na primeira página.
A API aceita como parâmetro de entrada o binário dos arquivos a serem processados, codificado em uma string de texto no padrão base64 conforme a RFC 4648. Da mesma forma, as imagens retornadas nas respostas das rotas serão codificadas em base64 seguindo o padrão RFC 4648.Para arquivos PDF protegidos por senha, a senha deve ser fornecida em uma string base64 (padrão RFC 4648) e enviada no parâmetro de entrada filePassword
.
Características e limitações dos arquivos de imagem#
O limite máximo de upload do mostQI é de 50MB para PDFs e 20 MB para arquivos em formato de imagens, e com o limite mínimo de área de 5k pixels ou 50 pixels de lado.
Arquivos PDF que contenham mais de 50 páginas serão recusados. Para arquivos com mais de 5 páginas, deve-se usar a rota assíncrona para evitar timeout.
Devido à grande variação de qualidade nos dispositivos de captura disponíveis nos smartphones, não há recomendações mínimas em termos de resolução ou tamanho da imagem.
Para reduzir o tamanho do arquivo a ser enviado para o mostQI, recomenda-se a compressão JPG. Não recomendamos operações de redimensionamento da imagem, pois essa operação pode comprometer a qualidade em grau maior que a compressão JPG.
Em alguns casos, a compressão com até 80% de perdas é aceitável, mas há uma expressiva redução no tamanho da imagem. A compressão com perdas pode prejudicar o desempenho da leitura, portanto níveis muito altos devem ser usados apenas para imagens muito grandes.
Imagens que extrapolem o limite superior de 9M pixels serão redimensionadas (de maneira proporcional) para que se encaixem no limite.
A API do mostQI oferece parâmetros opcionais que possibilitam solicitar imagens transformadas com base no arquivo original. Essas imagens são fornecidas na resposta da API em formato base64 (padrão RFC 4648) e estão disponíveis nas seguintes rotas: Content Extraction, VIO Extraction e Smart Invoice Extraction.Imagem original enviada na requisição.
Os parâmetros disponíveis são os seguintes:returnImage#
returnImage
: Se este parâmetro for incluído na requisição com o valor 'true', a API retornará recortes dos binários das imagens dos documentos tipificados, corrigindo a perspectiva.Imagem da frente do documento com perspectiva corrigida.
Imagem do verso do documento com perspectiva corrigida.
returnedImageQuality#
returnedImageQuality
: Permite definir a qualidade da imagem de deskew retornada na rota através do parâmetro returnImage. O valor padrão (quando não informado) é 75.returnCrops#
returnCrops
: Se este parâmetro for incluído na requisição com o valor 'true', a API retornará os recortes dos binários das imagens contidas dentro de um documento tipificado, corrigindo a perspectiva. Esses recortes podem incluir fotos, assinaturas, códigos de barras e impressões digitais. Consulte a lista de documentos lidos para visualizar todos os crops disponíveis.Recorte da imagem da digital (tag has=fingerprint).
Recorte da foto (tag has=photo).
Recorte da assinatura (tag has=signature).
Resposta padronizada#
Todos os métodos da API possuem um corpo de resposta padronizado:{
"result": {},
"requestId": "",
"elapsedMilliseconds": 0,
"status": {
"message": "Ok",
"code": "200",
"errors": null
}
}
A ordem dos elementos dentro do result
não é garantida. É obrigatório utilizar o campo name
como referência para encontrar os valores.
Response#
Nome | Tipo | Nulável | Descrição |
---|
result | Variável | Sim | Lista contendo o resultado do método (consulte na documentação específica de cada um). |
requestId | String | Não | Código único de identificação da solicitação ao servidor, que será registrado no histórico de consumo dos serviços. |
elapsedMilliseconds | Integer | Não | Tempo em milissegundos de duração do processamento. |
status | Object | Não | Objeto contendo o código e mensagem de status da resposta. |
Status#
Nome | Tipo | Nulável | Descrição |
---|
code | String | Não | Código de status interno. |
message | String | Sim | Mensagem de retorno do status. |
errors | Lista de Error | Sim | Lista de objetos do tipo Error, o formato é variável. |
Contabilização do consumo#
As requisições bem-sucedidas serão contabilizadas para fins de faturamento, com diferenciações na forma de contabilização conforme o serviço consumido. Todos os itens faturáveis estão listados no Relatório de Consumo (Consumption Report), devidamente identificados pelo requestId, data e hora da requisição, bem como outros detalhes sobre o resultado do consumo.Para os serviços que utilizam o recurso de imagem, conforme listados abaixo, haverá a contabilização pela quantidade de documentos processados:License Plate Recognition
Multi Page Content Extraction
Documentos tipificados/classificados que retornam resultados de processamento são contabilizados. Além disso, mesmo páginas sem identificação de documentos (páginas em branco) são processadas e contabilizadas. Essas páginas aparecem no Relatório de Consumo com a indicação "utp" (untyped page) na coluna Details.Exemplo de parte da estrutura do Relatório de Consumo, apresentando a contabilização de itens tipificados e utp para o consumo de rotas que utilizam recurso de imagem.
O status 200 ("message": "Ok", "code": "200") indica sucesso na comunicação com a API e no processamento do arquivo, mas não garante que uma imagem foi identificada no arquivo processado. Caso nenhuma imagem seja reconhecida, o campo "result" retornará vazio, como mostrado no exemplo abaixo:{
"result": [],
"requestId": "tK6fnYJrxk21T7Mt3OEEb",
"elapsedMilliseconds": 1322,
"status": {
"message": "Ok",
"code": "200",
"errors": null
}
}
O cálculo de consumo e, consequentemente, de cobrança seguem os seguintes critérios para a determinação do volume de imagens processadas:Imagem de um único documento: Uma requisição REST contendo uma imagem, seja ela tipificada ou não, resulta na contagem de uma imagem processada.
Imagens de múltiplos documentos: Se a requisição REST contiver várias imagens, cada imagem será contabilizada, independentemente de ter sido tipificada ou não. Páginas sem identificação de imagens também são incluídas, pois foram processadas.
Para documentos com frente e verso distintos, como RGs e CNHs (não abertas), duas imagens são contabilizadas: uma para a frente e outra para o verso.
No caso do RG, a extração frente e verso sempre contabiliza duas imagens, mesmo que as imagens sejam capturadas separadamente ou em uma única captura (documento aberto).
Para a CNH, a contabilização depende da forma de envio:
CNH aberta: Apenas uma imagem é contabilizada.
CNH fechada: Duas imagens são processadas, uma para a frente e outra para o verso, gerando a contagem de duas imagens.
Armazenamento de dados e LGPD#
O mostQI não armazena as imagens enviadas pelos clientes e todo o processamento ocorre em memória volátil, nos deixando em conformidade com a LGPD.