O que é um arquivo J2K?

Um arquivo J2K contém o mesmo fluxo de código bruto JPEG 2000 que outras ferramentas nomeiam como .j2c ou .jpc; a extensão .j2k é uma convenção de nome de arquivo para esse mesmo formato, não um codec ou contêiner distinto. Seu conteúdo se concentra em dados comprimidos de imagem, não em metadados de contêiner.

Como os arquivos J2K funcionam

.j2k é um dos vários nomes de um fluxo de código bruto JPEG 2000. As ferramentas do OpenJPEG tratam .j2k, .j2c e .jpc como o mesmo formato de entrada, e o registro da IANA para o tipo de mídia de fluxo de código image/j2c lista j2k como extensão de arquivo. A decodificação começa pelos próprios cabeçalhos do fluxo de código, o marcador SOC e o segmento marcador SIZ, não por uma assinatura ou marca de contêiner, e os segmentos marcadores seguintes registram o estilo de codificação, a quantização e a ordem de progressão. Dentro do fluxo, uma imagem é codificada como um ou mais blocos retangulares, e os dados comprimidos de cada bloco são divididos em pacotes, cada um pertencente a uma camada de qualidade, a um nível de resolução, a um componente e a um precinto; a ordem dos pacotes de um bloco é o que permite a um decodificador parar antes do fim ou decodificar com resolução reduzida. Um pipeline que precisa de metadados de contêiner pode envolver o mesmo fluxo de código em um arquivo JP2, que o armazena em uma caixa de fluxo de código contíguo após as caixas de assinatura JPEG 2000, de tipo de arquivo e de cabeçalho JP2.

Informações essenciais

  1. Como um pipeline deve detectar um arquivo .j2k? Pelo conteúdo. Um fluxo de código bruto começa com os bytes FF 4F FF 51, enquanto um arquivo JP2 começa com a caixa de assinatura de 12 bytes 00 00 00 0C 6A 50 20 20 0D 0A 87 0A. O opj_decompress do OpenJPEG mostra a ordem mais segura para confiar nessas informações: ele lê os bytes iniciais e, se eles não corresponderem à extensão, emite um aviso de que a extensão está incorreta e decodifica de acordo com os bytes. Uma entrada cujos bytes iniciais não correspondam a nenhuma assinatura conhecida é rejeitada como formato de entrada desconhecido; a exceção é um arquivo chamado .jpt, que ele aceita pela extensão sem essa verificação.
  2. O que determina se uma ferramenta grava um fluxo de código .j2k ou um arquivo JP2? Geralmente, o nome do arquivo de saída. O opj_compress do OpenJPEG documenta .j2k e .jp2 como suas extensões de saída, e o Pillow escolhe a forma pela extensão, a menos que no_jp2 esteja definido, o que força o uso de um fluxo de código bruto. Renomear um arquivo existente não converte nada: os bytes continuam sendo um fluxo de código ou um arquivo JP2, independentemente do sufixo.
  3. Um arquivo .j2k tem perdas? O nome não informa. A sintaxe básica permite tanto o filtro wavelet reversível 5-3 quanto o irreversível 9-7, e tanto o opj_compress do OpenJPEG quanto o Pillow usam o filtro reversível, salvo indicação em contrário. Um filtro reversível ainda não comprova que o conteúdo seja sem perdas: taxas de compressão ou metas de qualidade fornecidas ao codificador podem fazer com que as camadas de qualidade tenham perdas, e a ausência de perdas no arquivo completo depende da meta da última camada. O manual de opj_compress descreve seu exemplo -r 20,10,1 como “comprimir 20x, depois 10x, depois sem perdas”: sem perdas quando todas as camadas são decodificadas, com perdas quando apenas as anteriores são decodificadas. T.800 também observa que uma transformação reversível pode ser usada em fluxos de código truncados para oferecer compressão com perdas.
  4. O que a ordem de progressão altera? A ordem em que os pacotes de cada bloco aparecem e, portanto, o que uma leitura parcial desse bloco produz. T.800 define cinco ordens, escritas como LRCP, RLCP, RPCL, PCRL e CPRL, sinalizadas no segmento marcador COD e alteráveis com segmentos marcadores POC. A ordem que prioriza camadas (LRCP) permite que a qualidade melhore à medida que os dados chegam; a ordem que prioriza resolução (RLCP) entrega primeiro versões de baixa resolução de todos os componentes. Como a ordem se aplica dentro de um bloco, ela não garante uma visualização antecipada da imagem inteira em um arquivo com múltiplos blocos: T.800 permite, mas não exige, que um codificador intercale partes de blocos diferentes e, sem esse intercalamento, uma leitura sequencial só alcança os dados de um bloco após todos os dados dos blocos armazenados antes dele. T.800 também permite truncar os dados de um bloco descartando os bytes finais, desde que os parâmetros do segmento marcador de comprimento do bloco reflitam o truncamento, de modo que a ordem escolhida determina o que um bloco truncado ainda contém.

Quando os arquivos J2K são importantes

A detecção de formato deve examinar o conteúdo do arquivo, pois as extensões, por si só, não distinguem de forma confiável as variantes de JPEG 2000. Selecionar um analisador exclusivo para contêineres pode causar uma falha ao processar um arquivo J2K válido.

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional

Conecte uploads, processamento, IA, armazenamento e entrega por meio de uma única API declarativa, com o stack de codificação, o ajuste de escala e as constantes mudanças de formatos gerenciados para você.

Experimente a Transloadit gratuitamente