Convertir MOV en JXL

JPEG XL est la modernisation du format JPEG développée par le JPEG Committee, et son point fort à qualité égale est une compression meilleure que ses prédécesseurs. Le revers est une compatibilité plus étroite : Safari ne supporte JXL qu’en lecture depuis macOS Sonoma, Firefox l’a retiré en 2022, et beaucoup d’outils de graphisme et de chaînes d’e-mailing ne le lisent pas. C’est un format d’avenir, pas un format de présent pour la plupart des usages.

Pour un site web qui sert un public technophile et qui contrôle les navigateurs de ses visiteurs, c’est un allié précieux. Pour un visuel qui sera ré-enregistré par un graphiste, passé à un logiciel ancien, ou affiché dans un email, c’est un pari. Le pipeline ne fait pas la différence : il produit du JXL à 82, peu importe la destination, et c’est à vous de décider si la destination sait le lire.

Le moteur raster passe la qualité 82 à l’encodeur JXL, et `@jsquash/jxl` interprète ce paramètre avec `lossless: false` par défaut. C’est documenté dans le registre des caractéristiques comme `losslessWritten: false` sur JXL, WebP, AVIF, GIF et ICO. Pour un usage web, c’est ce qu’il faut : une image 1080p en JXL à 82 pèse entre 100 et 250 Ko selon le contenu, contre 200 à 400 Ko pour le même visuel en WebP ou AVIF.

Pour un cas où le sans perte est une exigence, il faut viser le PNG. JXL peut encoder en sans perte, mais le pipeline ne l’appelle jamais sur ce chemin, et c’est explicite. La qualité 82 est un compromis mesuré entre la taille du fichier et la qualité perçue, choisi pour produire des images qui passent sans avertissement dans une galerie web tout en restant sous la barre des 250 Ko pour un visuel 1080p.

Le champ de timestamp est en secondes depuis le début, et le défaut est 0. Le pipeline prend la dernière image dont l’heure de début tombe à ou avant la seconde tapée, sans mise à l’échelle intermédiaire. Aucune réduction de résolution n’est appliquée : un MOV 1080p sort en 1920 par 1080, un MOV 4K en 3840 par 2160, et la qualité 82 est appliquée à l’image pleine taille.

Pour un hero de page d’accueil, c’est ce qu’il faut. Pour une vignette qui sera redessinée à 200 pixels de large, c’est trop grand et il vaut mieux redimensionner après. Pour un visuel destiné à un portfolio, c’est exactement la taille attendue par les navigateurs, qui redessinent de toute façon à la taille d’affichage sans perte de qualité visible.

Le décodeur rend des pixels et l’encodeur accepte des pixels. Aucune valeur EXIF, GPS, XMP, IPTC ou profil ICC ne traverse la conversion, et c’est explicite dans le pipeline. Le MOV source peut porter des informations de timecode, des coordonnées de prise de vue, un profil colorimétrique ou des notes d’auteur, et tout cela s’arrête au moment du décodage.

Pour un usage web, c’est précisément ce qu’il faut : un JXL qui part en ligne ne porte rien qui permette de tracer l’appareil, le lieu ou les réglages. Pour un usage d’archive, c’est un défaut qu’il faut compenser avec un outil d’édition après la conversion. La règle vaut pour tous les formats raster de ce site, et c’est explicite dans la note de la règle qui les régit.

JXL est plus récent que ses concurrents et plus économe en bande passante à qualité égale. Le revers est une compatibilité plus étroite, comme dit plus haut, et c’est un arbitrage à faire en fonction de la destination. Pour un site qui contrôle ses navigateurs et qui veut servir les formats les plus modernes d’abord, JXL est une bonne tête de liste dans une implémentation de picture.

Pour un site grand public servi à des navigateurs de la décennie, AVIF est plus largement supporté et presque aussi économe. Pour un visuel qui sera partagé hors d’un site web, JPG reste la valeur de repli universelle. La décision est celle de la destination, et c’est la même chose qu’avec AVIF ou WebP : les trois formats à 82 produisent une image de qualité visible équivalente, et c’est la compatibilité qui tranche.

mediabunny s’appuie sur les décodeurs que le système d’exploitation expose à WebCodecs. Un MOV en H.264 passe sans condition. Un MOV en HEVC passe si le navigateur a le décodeur, ce qui dépend de l’OS et du matériel. Un MOV en ProRes, codec professionnel d’Apple, n’est en revanche pas décodé par un navigateur, et la conversion s’arrête avec un message d’erreur explicite.

Pour un MOV issu d’un iPhone ou d’un iPad récent, la vidéo est en HEVC, et la conversion dépend du navigateur. Pour un MOV issu de Final Cut ou de Compressor, la vidéo est en ProRes et la conversion refusera. La règle utile est de vérifier le codec avant la conversion, et MediaInfo en ligne de commande fait l’inventaire en quelques secondes.

Le pipeline ne fait pas de mise à l’échelle par défaut, et la sortie est aux dimensions pixel exactes de la vidéo. Pour un MOV 1080p, c’est 1920 par 1080. Pour un MOV 4K, c’est 3840 par 2160, et le JXL à 82 d’une telle image pèse entre 300 Ko et 800 Ko selon le contenu.

Pour un hero, c’est ce qu’il faut. Pour une vignette qui sera redessinée à 200 pixels, c’est trop grand et il vaut mieux redimensionner après. Pour un visuel envoyé par mail, la pleine taille d’une image 4K est excessive et c’est une étape de redimensionnement à ajouter dans la chaîne.

La cible est une image fixe, et l’audio du MOV n’a aucun emplacement dans un JXL. Le pipeline ne touche pas aux pistes audio, et le JXL produit est strictement l’image, sans son, sans sous-titre et sans chapitre. Le MOV source n’est pas modifié et peut être reconverti vers une cible vidéo sans perte autre que le temps écoulé.

Pour un cas où le son est nécessaire, c’est la mauvaise conversion et il faut viser une cible vidéo ou audio. Le JXL n’a aucune capacité sonore et aucune conversion ne lui en ajoutera une. C’est la même réponse que pour les autres paires `video > image` du site.

Le décodage, l’échantillonnage et l’encodage tournent dans l’onglet du navigateur, sur votre processeur, sans rien envoyer nulle part. Le niveau gratuit accepte les fichiers jusqu’à 100 Mo, et il n’y a pas de compte, pas de quota journalier, pas de filigrane ajouté au JXL produit.

Pour un visuel client, une image sous embargo ou une photo qui ne doit pas sortir de l’appareil, c’est la seule forme sous laquelle la conversion est vraiment locale, vérifiable dans l’onglet réseau de vos outils de développement pendant qu’une conversion tourne. Aucune requête ne porte le fichier, et c’est la seule affirmation de confidentialité qui ait un sens vérifiable.