Qu’est-ce qu’un fichier J2K ?

Un fichier J2K contient le même flux codé JPEG 2000 brut que d’autres outils nomment .j2c ou .jpc ; l’extension .j2k est une convention de nommage pour ce même format, et non un codec ou un conteneur distinct. Son contenu porte sur les données d’image compressées, et non sur les métadonnées de conteneur.

.j2k est l’un des noms d’un flux codé JPEG 2000 brut. Les outils d’OpenJPEG traitent .j2k, .j2c et .jpc comme un même format d’entrée, et l’enregistrement IANA du type de média de flux codé image/j2c répertorie j2k comme extension de fichier. Le décodage commence à partir des en-têtes propres au flux codé, le marqueur SOC et le segment de marqueur SIZ, et non à partir d’une signature ou d’un identifiant de marque de conteneur, et les segments de marqueur suivants indiquent le style de codage, la quantification et l’ordre de progression. Dans le flux, une image est codée en une ou plusieurs tuiles rectangulaires, et les données compressées de chaque tuile sont divisées en paquets appartenant chacun à une couche de qualité, un niveau de résolution, une composante et un précinct ; l’ordre des paquets d’une tuile permet au décodeur de s’arrêter avant la fin ou de décoder à résolution réduite. Une chaîne de traitement qui a besoin de métadonnées de conteneur peut envelopper le même flux codé dans un fichier JP2, qui le stocke dans une boîte de flux codé contigu après les boîtes de signature JPEG 2000, de type de fichier et d’en-tête JP2.

Comment une chaîne de traitement doit-elle détecter un fichier .j2k ? Par son contenu. Un flux codé brut commence par les octets FF 4F FF 51, tandis qu’un fichier JP2 commence par la boîte de signature de 12 octets 00 00 00 0C 6A 50 20 20 0D 0A 87 0A. L’outil opj_decompress d’OpenJPEG montre l’ordre de confiance le plus sûr : il lit les premiers octets et, s’ils ne correspondent pas à l’extension, affiche un avertissement indiquant que l’extension est incorrecte et décode selon les octets. Une entrée dont les premiers octets ne correspondent à aucune signature connue est rejetée comme format d’entrée inconnu ; l’exception est un fichier nommé .jpt, accepté selon son extension sans cette vérification.
Qu’est-ce qui détermine si un outil écrit un flux codé .j2k ou un fichier JP2 ? Généralement, le nom du fichier de sortie. La documentation de l’outil opj_compress d’OpenJPEG répertorie .j2k et .jp2 comme extensions de sortie, et Pillow choisit la forme selon l’extension, sauf si no_jp2 est défini, ce qui impose un flux codé brut. Renommer un fichier existant ne convertit rien : les octets restent ceux d’un flux codé ou d’un fichier JP2, quel que soit le suffixe.
Un fichier .j2k est-il avec perte ? Son nom ne le dit pas. La syntaxe de base autorise aussi bien le filtre en ondelettes réversible 5-3 que le filtre irréversible 9-7, et l’outil opj_compress d’OpenJPEG comme Pillow utilisent le filtre réversible sauf instruction contraire. Un filtre réversible ne prouve toutefois pas que le contenu est sans perte : les taux de compression ou les objectifs de qualité fournis à l’encodeur peuvent rendre les couches de qualité avec perte, et le caractère sans perte du fichier complet dépend de l’objectif de la dernière couche. Le manuel de opj_compress décrit son exemple -r 20,10,1 ainsi : « compresser 20x, puis 10x, puis sans perte » : le résultat est sans perte lorsque toutes les couches sont décodées, et avec perte lorsque seules les premières le sont. T.800 précise également qu’une transformation réversible peut être utilisée dans des flux codés tronqués pour produire une compression avec perte.
Que change l’ordre de progression ? L’ordre d’apparition des paquets de chaque tuile, et donc le résultat d’une lecture partielle de cette tuile. T.800 définit cinq ordres, notés LRCP, RLCP, RPCL, PCRL et CPRL, signalés dans le segment de marqueur COD et modifiables au moyen de segments de marqueur POC. L’ordre donnant la priorité aux couches (LRCP) permet à la qualité de s’améliorer à mesure que les données arrivent ; celui donnant la priorité à la résolution (RLCP) fournit d’abord des versions à basse résolution de toutes les composantes. Comme cet ordre s’applique à l’intérieur d’une tuile, il ne garantit pas un aperçu rapide de l’image entière dans un fichier à plusieurs tuiles : T.800 autorise un encodeur à entrelacer les parties de différentes tuiles, sans l’y obliger, et, sans entrelacement, une lecture séquentielle n’atteint les données d’une tuile qu’après toutes les données des tuiles stockées avant elle. T.800 permet également de tronquer les données d’une tuile en supprimant des octets à la fin, à condition que les paramètres du segment de marqueur de longueur de tuile reflètent cette troncature ; l’ordre choisi détermine donc ce que contient encore une tuile raccourcie.

La détection du format devrait examiner le contenu du fichier, car les extensions seules ne permettent pas de distinguer de manière fiable les variantes de JPEG 2000. Le choix d’un analyseur limité aux conteneurs peut entraîner un échec avec une ressource J2K valide.

Qu’est-ce qu’un fichier J2K ?

Fonctionnement des fichiers J2K

Points clés

Quand les fichiers J2K sont utiles

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle