SimuLook · Notes de l'appareil

Les hautes lumières et les ombres avancent par demi-crans, et nous les arrondissions

Réglez les hautes lumières sur un Fujifilm récent et la molette ne fait pas −1, 0, +1. Elle fait −1, −0,5, 0, +0,5, +1. Pareil pour les ombres. Ces deux commandes, seules parmi les réglages de tonalité, avancent par demi-crans.

Notre application les stockait en nombres entiers. Et tout ce qui se trouvait en aval aussi.

Ce que cela coûtait vraiment

Trois des sept emplacements de l’appareil sur lequel nous calibrons sont réglés à −0,5. Lisez l’un de ces emplacements dans l’application et la valeur était arrondie à l’entrée — avant d’être enregistrée, avant d’être publiée, avant d’être réécrite.

Les conséquences s’empilent d’une manière pire qu’il n’y paraît :

  • Une recette lue sur votre appareil n’était pas la recette qui était dans votre appareil. Elle en était à un demi-cran près.
  • Publiez-la et tous ceux qui l’enregistraient recevaient la version arrondie.
  • Réécrivez-la dans un emplacement et l’appareil se retrouvait avec une valeur qu’il n’avait jamais eue.
  • Comparez-la à la photographie avec laquelle elle a été prise et l’application annonçait une correspondance exacte, parce que les deux côtés avaient été arrondis jusqu’à s’accorder.

Le dernier point est le pire. Tout l’intérêt de comparer une photo à votre bibliothèque est de nommer la différence. L’arrondi transforme une différence réelle en une fausse confirmation.

Le commentaire était déjà là

L’arrondi n’était pas un oubli que personne n’avait remarqué. Il y avait, juste au-dessus, un commentaire qui disait que le modèle stockait la tonalité en entier, que les boîtiers actuels proposent des demi-crans, et que c’était une limite de l’application et non de l’appareil.

Quelqu’un a écrit cela, correctement, puis est passé à autre chose. C’est resté vrai pendant des mois.

Nous le mentionnons parce que la leçon n’est pas « vérifiez vos types ». C’est qu’une limite connue écrite dans un commentaire n’est pas une limite corrigée, et qu’une base de code portera volontiers une description exacte de son propre bug aussi longtemps que vous la laisserez faire.

Ce qui a rendu la correction délicate

La réparation évidente est de passer le champ en décimal et d’écrire −0,5 sur le serveur. Cela aurait cassé l’application pour tous ceux qui n’avaient pas mis à jour.

Les versions déjà livrées décodent ce champ comme un entier. Devant une fraction, elles ne se dégradent pas — elles lèvent une exception. Et comme une page du fil communautaire est décodée d’un seul bloc, une seule recette en demi-cran aurait vidé Découvrir pour tous les utilisateurs restés sur l’ancienne version. Une recette, le fil de tout le monde.

La valeur voyage donc deux fois. L’ancien champ continue de porter, inchangé, le nombre arrondi que ces clients lisaient déjà. Un second champ porte la valeur exacte dans l’unité de l’appareil — le boîtier stocke la tonalité en dixièmes, donc −0,5 vaut −5, ce qui est un entier et contourne la question de savoir comment un décimal survit à un aller-retour.

Deux tests tiennent cette promesse à la place d’un commentaire : l’un décode ce que l’application actuelle écrit dans une structure taillée sur l’ancien contrat et vérifie qu’elle y lit toujours un nombre entier ; l’autre fait l’aller-retour sur chaque champ, de sorte qu’une propriété oubliée dans l’encodeur écrit à la main fait échouer la suite au lieu de perdre discrètement l’un de vos réglages.

Tout ce qui était en aval a dû suivre

Une valeur n’est préservée que si rien sur le trajet ne l’arrondit à nouveau.

Les deux éditeurs avancent maintenant par demi-crans. Un éditeur à pas entier aurait réarrondi la recette dès l’ouverture par son propriétaire — la même perte, une frontière plus loin. La voie d’écriture vers l’appareil envoie les dixièmes exacts, si bien que réécrire un emplacement lu sur le même boîtier restitue maintenant ce qui s’y trouvait vraiment. La vérification en relecture garde sa tolérance au bruit de virgule flottante sans pardonner un vrai écart d’un demi-cran. Et le comparateur de photos signale −0,5 face à 0 comme une différence, et la nomme.

Pourquoi l’écrire

Parce que l’argument de l’application est qu’elle vous dit la vérité sur vos réglages, et pendant des mois elle vous disait discrètement quelque chose de faux d’un demi-cran.

La correction est en place. Les six recettes que nous avions publiées ont été corrigées à leurs valeurs exactes. Mais une application qui prétend être précise doit être capable de dire quand elle ne l’était pas, sinon la prétention n’est que du marketing.

Écrit pendant le développement de SimuLook, une app pour lire et écrire des recettes de simulation de film Fujifilm. Voir les appareils pris en charge · Lire les autres notes