Obtenez un fichier sous la taille qu'un formulaire demande

Kibi-octets, kilo-octets et le nombre du formulaire

Le champ de taille cible prend un nombre de kibi-octets. Un kibi-octet vaut 1024 octets et non 1000, donc une cible de 200 vaut 204 800 octets. Quand un formulaire dit 200 Ko il peut vouloir dire les 200 000 octets décimaux, ce qui fait environ 195 Kio : lisez donc l’unité qu’il utilise et convertissez au lieu de recopier le nombre.

La différence entre les deux unités est de l’arithmétique, et vient de deux constantes et rien d’autre : 1024 octets par kibi-octet, et 1000 octets par kilo-octet décimal. Écrivez d’abord le plafond en octets (200 Ko décimaux font 200 000 octets), puis divisez-le par 1024 : c’est le nombre que ce champ attend.

Le lire dans l’autre sens est la même arithmétique avec les nombres inversés, et c’est le sens qui mord. Une cible de 100 représente plus d’octets que n’en autorise un 100 Ko décimal, si bien qu’un fichier sorti exactement à cette cible peut dépasser le plafond qu’on vous a donné. Arrondissez le nombre vers le bas plutôt que vers le haut et le fichier reste en dessous. Rien ici n’est une économie ni un pourcentage : ce sont les mêmes deux constantes dans les deux sens.

Un mégaoctet sur une fiche de spécifications n’est pas toujours décimal non plus. Si la fiche définit son propre Mo en unités de 1024 octets, alors un plafond de 1 Mo vaut 1024 Kio, et c’est 1024 que ce champ prend. Quand une fiche donne un nombre et aucune unité, l’ambiguïté est à la fiche et non à l’outil, et c’est la ligne terminée qui tranche : elle montre la taille avant et la taille après en Kio, l’unité que ce champ prend, si bien qu’un plafond en Kio se lit directement dessus. Pour un plafond décimal, comparez la ligne à la colonne de droite du tableau, ou lisez la taille en octets du fichier que vous téléchargez.

Une cible est un plafond avec une bande en dessous

C’est la différence qui compte le plus sur cette page. Une cible est une limite sous laquelle ou à laquelle la sortie doit se situer, pas une taille que l’outil va produire. L’outil encode d’abord à votre réglage de qualité, puis cherche une qualité dont la sortie tient sous votre nombre, dans un sens ou dans l’autre.

Quand le premier encodage dépasse la cible, la recherche abaisse la qualité, jusqu’à 1 au plus bas, jusqu’à ce que le fichier tienne. Quand le premier encodage arrive nettement en dessous de la cible, la recherche va dans l’autre sens : vers le haut depuis votre réglage, jamais au-delà de 100, pour la plus haute qualité qui tient encore. Seule cette recherche vers le haut est bornée par votre réglage. C’est en abaissant la qualité que l’outil atteint votre nombre, si bien qu’un fichier qui était au-dessus de la cible peut revenir plus rugueux que la qualité que vous avez choisie.

La recherche vise une bande : au plus votre nombre, et au moins 95% de celui-ci. La qualité avance par nombres entiers, et un pas peut sauter par-dessus toute la bande, si bien que le fichier tombe dedans quand un pas y tombe, et c’est l’encodage le plus proche sous votre cible quand aucun pas n’y tombe. C’est la forme honnête de la garantie. Quand une qualité tient, le fichier est à votre nombre ou en dessous ; ce n’est pas la promesse qu’il atterrit juste sous votre chiffre, ou à moins de 5% de celui-ci.

Une cible supérieure à ce que le format peut produire est un cas qui mérite d’être nommé. L’échelle de qualité s’arrête à 100, donc une cible bien plus grande que le meilleur encodage de l’image ne peut pas être remplie en grossissant le fichier. Vous obtenez alors le plus gros fichier que le format a produit, qui est toujours sous votre nombre, et la ligne signale la cible comme atteinte, parce que le fichier est au plafond ou en dessous. Le verdict de la ligne est pris sur les octets que vous téléchargez réellement, comptés après l’EXIF que vous avez demandé de conserver, pour qu’on ne vous dise jamais qu’une limite a été respectée quand le fichier sur votre disque la dépasse.

Quelles tailles un réglage de qualité peut atteindre, et lesquelles exigent un redimensionnement d’abord

La qualité est le seul bouton que cette recherche dépense, donc la question de savoir si votre nombre est même possible a une réponse honnête qui tient en plus d’une partie. Le cas ordinaire : un plafond plus bas n’est qu’une bande plus étroite où atterrir. La recherche abaisse la qualité depuis votre réglage, jusqu’à 1 au plus bas, jusqu’à ce que le fichier tienne, et remonte depuis votre réglage quand le premier encodage arrive nettement en dessous de votre nombre.

Trois cas s’écartent de ce cas ordinaire, et chacun a sa propre réponse.

Une image encore au-dessus de la cible à la qualité 1 ne l’atteint pas. La qualité 1 est le plancher de l’échelle, il ne reste donc aucun réglage plus bas à dépenser, et la ligne signale l’échec. Ce qu’il reste à dépenser, ce sont des pixels.

Un PNG ne peut rien dépenser du tout dans cette recherche, parce qu’il est sans perte et que la qualité n’est pas son bouton. Une section est consacrée à ce cas plus bas.

Un bloc EXIF conservé s’écrit après la recherche plutôt que dans le budget sur lequel elle a travaillé, si bien qu’un fichier qui tenait peut ressortir au-dessus du plafond dès que vous activez la conservation des métadonnées. Laissez ce contrôle désactivé quand une limite stricte compte, ce qui est aussi le réglage par défaut.

Un plafond au-dessus de ce que produit la qualité 100 n’est pas un échec non plus : vous obtenez l’encodage en qualité 100, qui reste sous votre nombre, et la ligne dit que la cible a été atteinte. La section ci-dessus expose ce cas en détail.

L’ordre qui fonctionne est donc le même dans tous les cas : réglez une largeur avec le contrôle de redimensionnement et gardez la cible dans la même passe, car l’outil redimensionne d’abord puis cherche la qualité sur la plus petite image. La moitié de la largeur, c’est un quart des pixels, et la taille baisse avec les pixels, alors que la qualité ne change que ce que coûte chaque pixel. Le format de sortie déplace aussi le nombre, et la page WebP couvre ce choix, y compris le fait qu’une sortie JPEG aplatit la transparence sur du blanc avant de s’encoder.

Quand la ligne dit que la cible a été manquée

Un échec mérite d’être lu avant de réessayer. Il a été décidé sur le fichier que vous téléchargez et non sur l’encodage qui s’en est approché, si bien qu’un fichier que la recherche a presque atteint sera signalé comme au-dessus de la limite quand il l’est.

Il y a trois raisons honnêtes à un échec.

Redimensionnez dans la même passe : réglez une largeur avec le contrôle de redimensionnement et laissez la cible où elle est. La qualité 1 est le plancher de la recherche, si bien qu’un fichier qui la manque ne peut pas être réparé en abaissant encore la qualité, et moins de pixels le peuvent puisque la taille baisse avec eux.

Quand vous avez activé la conservation des métadonnées, le bloc EXIF est écrit après la recherche, si bien qu’un fichier qui tenait peut ressortir au-dessus du plafond. Désactivez ce contrôle et relancez avant de redimensionner.

Si le fichier est un PNG, la recherche n’a jamais tourné, il n’y a donc pas de seconde tentative à attendre et rien à régler. La section ci-dessous couvre ce qu’un PNG peut et ne peut pas faire.

Quand vous gardez le résultat, jugez-le sur les deux aperçus que la ligne vous donne, l’image que vous avez choisie à côté de celle que vous allez obtenir. C’est cette comparaison qui décide si le fichier en vaut la peine à cette taille.

Un PNG sous une limite de taille

Le PNG est sans perte, il ignore donc entièrement le réglage de qualité, et c’est toute la raison pour laquelle une cible sur un PNG se comporte autrement qu’une cible sur un JPEG. Il n’y a pas de bouton à tourner vers le bas, si bien que la recherche n’a rien à dépenser : un PNG dont le premier encodage dépasse votre nombre ne reçoit aucun passage de qualité, et seule la passe d’optimisation ci-dessous peut encore le ramener sous votre nombre.

Il y a une passe de plus, et elle vaut la peine d’être connue. Chaque sortie PNG passe par une seconde passe d’optimisation, et ses octets ne sont gardés que s’ils sont moins nombreux que ceux du premier encodage. Un PNG peut donc revenir plus petit et peut passer sous une cible que le premier encodage a manquée, et il peut tout aussi bien ne pas y arriver. Rien ici ne met cette passe à la recherche de votre nombre : elle rend moins d’octets ou elle n’en rend pas.

Il reste donc deux chemins honnêtes vers un PNG plus petit. Moins de pixels marche dans tous les formats, si bien qu’un redimensionnement d’abord est la première chose à essayer. Un format de sortie avec perte marche aussi, et là la recherche de qualité a bien un bouton à dépenser, si bien que convertir le PNG en WebP est la réponse quand le plafond se trouve nettement en dessous de ce qu’un fichier sans perte de cette image peut atteindre. C’est un échange et non un gain gratuit : ce que l’encodeur abandonne pour atteindre le nombre est à regarder dans l’aperçu avant que vous gardiez le fichier.

Conserver les métadonnées ajoute des octets après la recherche

C’est une subtilité qui piège les gens. La recherche de taille s’exécute avant qu’un bloc EXIF ne soit écrit, parce que les encodeurs n’en écrivent aucun par défaut et que le bloc est ajouté tout à la fin quand vous demandez à le conserver. Le bloc n’est donc pas dans le budget sur lequel la recherche a travaillé.

L’outil traite cela honnêtement plutôt que discrètement : il compte les octets finaux, bloc compris, si bien que si conserver les métadonnées pousse le fichier au-dessus de votre cible, la ligne signale la cible comme manquée même si l’encodage seul était en dessous. Laissez le contrôle de conservation désactivé quand une limite stricte compte, ce qui est aussi le réglage par défaut.

Lire le verdict

Chaque ligne terminée porte l’une de deux déclarations quand vous fixez une cible : que le fichier est à cette taille ou en dessous, ou qu’il ne l’est pas. Lisez-la au lieu de supposer. La conversion ne signale jamais comme atteinte une cible qu’elle a manquée, si bien qu’une ligne qui dit qu’elle a été manquée signifie que le fichier sur votre disque dépasse la limite. La section sur les échecs plus haut dit quel changement la corrige.

Si un fichier est refusé

Une entrée de plus de 32 Mio est refusée sur sa seule taille, avant que ses octets soient lus. Une entrée de plus de 40 000 000 pixels est lue, puis refusée avant que quoi que ce soit ne la décode, parce que le nombre de pixels n’est connu qu’une fois son en-tête analysé. Ces deux nombres sont fixes et non une lecture de votre machine. Le fichier refusé nomme la limite qui l’a refusé, et tous les autres fichiers de la conversion se terminent quand même.

Que faire ensuite

Fixez la cible en Kio, lisez le verdict, et si elle a été manquée, redimensionnez l’image et relancez plutôt que de baisser encore la qualité. Si le plafond vous vient d’un formulaire ou d’un portail plutôt que de vous, la page des limites de photos lit cette fiche de spécifications et dit quelle partie de cette fiche cet outil peut tenir. Si votre travail est surtout constitué de photographies, la page de compression JPEG traite le côté qualité plus en détail, et si c’est le format qui est la question ouverte, la page WebP la traite.