Convertir RAF 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 RAF en WebP 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.

Le RAF porte un JPEG de prévisualisation que l’appareil génère à 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 X-Trans, pas d’application d’une balance des blancs différente de celle que l’appareil a choisie.

Pour un X-Trans, c’est l’information qu’il faut savoir : le filtre couleur propriétaire de Fujifilm complique sérieusement le dématriçage, et la conversion ne prétend pas le faire. Le WebP sort avec l’apparence que l’appareil a produite, et c’est le fichier qui est envoyé. Pour un développement alternatif, un logiciel dédié est nécessaire, et cette conversion n’est pas la voie.

Les capteurs Fuji récents enregistrent en 14 bits, et WebP porte 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 le RAF dans Capture One, darktable, ou Lightroom 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. Le profil de simulation de film n’est pas non plus exporté en tant qu’étiquette séparée.

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 informations, le RAF 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 Fujifilm. Un X-T5 à 40 mégapixels fait 7 728 par 5 192 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 Fuji complet entre 400 ko et 1,5 Mo en WebP à 82. Pour des vignettes pures, 1 024 pixels est suffisant et le fichier est plus proche de 120 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 RAF Fujifilm, même ceux d’un GFX 100S qui portent un TIFF complet en aperçu. 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 X-T5 à 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 GFX 100S à pleine taille peut prendre plusieurs secondes par fichier. C’est le moment où une largeur maximale devient non seulement utile pour la taille, mais aussi pour la vitesse. Régler la conversion à la résolution réellement utilisée en aval est un gain sur les deux tableaux.