Convertir ORF en WebP

WebP a été conçu pour servir vite : page web, miniature, image dans une conversation, vignettes dans un catalogue. Il est bon à cela et mauvais à d’autres choses. La conversion ORF en WebP vous donne un fichier deux à trois fois plus petit que le JPEG d’aperçu de l’appareil à qualité visible comparable, et rien qui ressemble à ce qu’une archive photographique attendrait.

Pour un envoi par messagerie, une page produit, un article en ligne, c’est exactement le bon outil. Pour un jeu d’archive qui doit rester lisible dans quinze ans, ce n’est pas le bon format, et la conversion ne prétend pas le contraire. Utilisez la sortie, ne l’emmagasinez pas comme source.

Le code de conversion définit une qualité unique par défaut et l’applique identiquement à JPEG, WebP, AVIF et JXL. Pour cette conversion, c’est 82 sur l’échelle WebP, ce qui correspond à un bon compromis visuel : peu d’artefacts visibles, fichier substantiellement plus petit que le JPEG d’aperçu de l’appareil.

Le contrôle est exposé si 82 n’est pas la bonne valeur. Monter au-delà de 90 fait des fichiers plus gros pour des gains visibles marginaux, descendre sous 70 fait des fichiers plus petits avec des artefacts que la compression en bloc du WebP rend très visibles. Pour un envoi, 80 à 85 est la plage utile ; pour un affichage en miniature, descendre à 70 est raisonnable.

L’ORF porte un JPEG de prévisualisation que l’appareil a généré à la capture. Le convertisseur trouve cet aperçu, le décode, et le réencode en WebP. Il n’y a pas de dématriçage, pas d’interprétation du capteur, pas d’application d’une balance des blancs différente de celle que l’appareil a choisie.

Cela signifie deux choses à la fois. La première : le fichier de sortie hérite de l’interprétation d’Olympus, picture style, courbe de tonalité, traitement du bruit compris. La seconde : il hérite aussi du sous-échantillonnage de chrominance du JPEG, qui est invisible à l’œil mais mesurable. Pour un envoi, l’un et l’autre sont sans importance ; pour un pipeline qui analyse la couleur, ils sont la limite à garder en tête.

Les capteurs Olympus modernes enregistrent en 12 bits, et WebP peut porter 8 bits par canal. C’est 8 bits qui arrive, parce que l’aperçu extrait est lui-même un JPEG 8 bits. La conversion n’invente pas de profondeur tonale qu’elle n’a pas, et le WebP écrit est à la précision du fichier que l’appareil a choisi de prévisualiser.

Pour une sortie qui sera ajustée fortement, c’est la mauvaise source. Le WebP s’adresse à un usage terminal, pas à un ajustement. Si l’étirement tonal est l’objectif, développez l’ORF dans un logiciel dédié et exportez un TIFF 16 bits qui portera la profondeur qu’il faut.

Le réencodage reconstruit les pixels et perd tout ce qui voyageait avec eux. L’EXIF, qui portait l’appareil, l’objectif, la focale, l’exposition, et parfois les coordonnées GPS, est retiré. Le profil ICC, qui décrivait l’espace colorimétrique d’interprétation de l’aperçu, est retiré aussi.

Pour un envoi, c’est exactement ce qu’il faut : un WebP de 800 ko ne devrait pas savoir où la photo a été prise. Pour un pipeline qui a besoin de ces métadonnées, l’ORF d’origine est l’autorité, et les informations doivent être lues de là et portées en parallèle. Le WebP n’est pas un maître de métadonnées, et le confondre avec un en est un usage coûteux.

Pour une photographie, un WebP à 82 fait généralement un fichier deux à trois fois plus petit qu’un JPEG à 82, à qualité perçue comparable ou légèrement meilleure. La raison technique est un prédicteur plus efficace, un partitionnement de blocs plus fin, et un meilleur traitement des zones plates, ce qui se voit sur les ciels, les murs et les zones défocalisées.

La raison de ne pas monter plus haut est qu’au-dessus de 90, l’amélioration visible est minime et le fichier gonfle rapidement. La raison de ne pas descendre sous 70 est qu’à ce niveau les artefacts de blocs WebP deviennent visibles sur les bords contrastés, et ils sont plus durs à tolérer que les artefacts JPEG à qualité comparable. Pour un envoi, 80 à 85 est la plage où WebP fait son travail ; en dehors, un autre format sera probablement meilleur.

La plupart des usages terminaux d’une image n’ont pas besoin de la pleine résolution Olympus. Un E-M1 III à 20 mégapixels fait 5 184 par 3 888 pixels, ce qui est énorme pour un message, une page, ou un produit de catalogue. Régler une largeur maximale est le levier qui rend la sortie prévisible.

2 048 pixels servent à peu près tout ce qui est consultation et envoi, et tombe un fichier Olympus complet entre 200 et 600 ko en WebP à 82. Pour des vignettes pures, 1 024 pixels est suffisant et le fichier est plus proche de 80 ko. Faire ce choix une fois pour tout le lot, et le tenir, est ce qui rend le résultat homogène.

Pour un destinataire qui ouvre le fichier sur une machine vieille ou dans un logiciel qui ne sait pas lire WebP, le JPEG est la réponse sûre. Aucun des grands navigateurs, visionneuses système, et logiciels de retouche ne refuse un JPEG, alors que WebP n’a été universellement lu qu’assez récemment.

Pour un envoi à un destinataire moderne, par messagerie, par page web, par application de chat qui compresse déjà, WebP à 82 est meilleure : plus petit, moins d’artefacts visibles, et généralement mieux toléré par les plateformes qui re-compressent à la sortie. La décision est moins « quel est le meilleur format » que « quel est le plus petit dénominateur commun acceptable » pour le destinataire réel.

L’intérêt d’un lot est la cohérence. Déposez la sélection complète, gardez la même qualité et la même largeur maximale, prenez le résultat en ZIP. Faire le travail en deux sessions introduit deux jeux de paramètres, et c’est comment une collection homogène devient un mélange à nettoyer.

Les fichiers d’entrée sont acceptés jusqu’à 100 Mo, ce qui couvre confortablement les ORF Olympus même anciens. Le navigateur fait le travail, et l’opération est vérifiable dans l’onglet réseau : aucune requête ne porte les fichiers, et c’est la condition qui rend l’utilisation sûre pour des images sous restriction.

WebP à 82 est gratuit en temps de calcul : la conversion prend sensiblement le même temps qu’un JPEG à la même qualité, et le navigateur la fait sans bloquer. La sortie d’un E-M1 III à pleine résolution avec une largeur maximale à 2 048 pixels est typiquement générée en moins d’une seconde par fichier, ce qui rend la conversion en lot praticable même pour un dossier de plusieurs centaines d’images.

Pour des résolutions plus élevées, le temps de décodage de l’aperçu et de réencodage grimpe, et un dossier de prises de vue en pose longue peut prendre plusieurs secondes par fichier. C’est le moment où une largeur maximale devient non seulement utile pour la taille du résultat, mais aussi pour la vitesse de la conversion. Régler la résolution réellement utilisée en aval est un gain sur les deux tableaux.