En essayant de placer une image dans /images, j’ai d’abord eu une erreur comme quoi cette image dépassait la taille autorisée par php. Est-ce que quelqu’un connait les limites en résolution ou taille de fichier autorisées sur framasite?
Après, afin de ne pas surcharger les bandes passantes des serveurs comme des utilisateurs, quels sont les conseils que vous pouvez me donner?
Je suis sous gentoo linux, avec entre autres gimp et imagemagick (donc convert) installés. Je pense qu’un petit script avec convert devrait faire l’affaire, mais comment obtenir une image d’une résolution adaptée aux écrans modernes, donc de pas trop faible dimension et résolution, qui ne soit en même temps pas trop grande en taille de fichier?
Je suis en train de faire des recherches et de tests. Il semble que la taille des fichiers est une question importante car les moteurs de recherche en tiennent compte dans leur appréciation de la rapidité d’un site pour établir leurs classement.
Une taille recommandée pour de grandes images semble être comprise entre 600 et 1000 pixels pour la plus grande dimension. Quand au format, le webp de google est conseillé. S’il est bien supporté sous windose, il semble que ce ne soit pas forcément le cas sous linux. Sous mon gentoo, il y a un USE flag pour cela, donc le support existe. En pratique, cela dépend des programmes.
Mes premiers tests de conversion m’ont montré que le webp donne la plus petite taille de fichier pour une qualité vraiment bonne, le png donne la plus grande taille pour une qualité comparable au webp, et le jpeg donne une taille assez petite mais pour une moins bonne qualité.
Un autre résultat est que convert donne des tailles légèrement inférieures que le gimp.
Des tests en utilisant l’option quality de convert me donne qu’avec -quality 80, la taille diminue un peu.
Pour un fichier png de 1920x1080 pour 2308kb, converti en 900x506, j’obtiens 758kb pour le png, 75kb pour le jpeg et 43kb pour le webp. Vu que le webp n’est pas encore universellement supporté, je vais en rester au jpeg.
En faisant ces tests, j’ai écris un petit script qui va bien. Attention, il dépend de convert et d’identify, donc d’imagemagick qui devrait être installé dans toutes les distributions linux, mais il ne teste pas leur présence. De même pour cut (coreutils) et sed (sed). J’ai ajouté un test pour bc, car il n’est pas installé par défaut.
Si vos noms de fichiers contiennent des caractères spéciaux, le seul qui est pris en compte est l’espace et en présence d’un autre de ces caractères, il a de fortes chances de planter.
Il converti les fichiers image du répertoire courant et ajuste leur taille et leur qualité. Si la plus grande dimension est inférieure la taille souhaitée, il ne change pas la taille, autrement il l’a réduit à cette taille et conserve la proportion largeur/hauteur. Les formats d’entrée et de sortie ainsi que la qualité et la taille sont passée en paramètres. Sans paramètre, un texte d’aide est sorti sur la console.
#!/bin/bash
# Copyrigth 2019 GPL v.3 or higher.
if [ -x /usr/bin/bc ]; then
echo "Good, bc is installed..."
else echo "Missing bc, please install bc and rerun $0"
exit 0
fi
usage() {
echo "$0 is intended to convert image files for the web."
echo "Missing parameter! Exiting..."
echo "Please rerun $0 with:"
echo ""
echo "$0 <ext1> <ext2> <quality> <size>"
echo ""
echo "where <ext1> is the input files extension without the dot,"
echo "<ext2> is the output files extension without the dot,"
echo "<quality> is the output file quality, typicaly between 60 and 85"
echo "and <size> is the maximum size in pixels of the output file,"
echo "typicaly between 600 and 1000 pixels."
echo ""
echo "Both <ext1> and <ext2> formats must be supported by convert."
echo ""
echo "Example: To convert all the png files in the current directory to jpg"
echo "with a quality factor of 80 and a biggest size of 900 pixels, run"
echo ""
echo "$0 png jpg 80 900"
echo ""
}
if [ -z "$4" ]; then
usage
exit 0
fi
size_ratio() {
SIZE_RATIO=`echo $1 / $2 | bc -l`
# we don't to increase the image size
if [ "`echo ${SIZE_RATIO} | cut -d. -f1`" == "" ]; then
SIZE_RATIO="1"
fi
}
for i in *.${1}; do
# seding for space in filename; other special characters not handled
GEOM=`identify "$i" | sed "s:${i} ::" | cut -d' ' -f2`
echo "Geometry for $i is $GEOM"
WIDTH_ORIG=`echo "${GEOM}" | cut -dx -f1`
HEIGHT_ORIG=`echo "${GEOM}" | cut -dx -f2`
if [ "${WIDTH_ORIG}" -gt "${HEIGHT_ORIG}" ]; then
BIGEST_DIM="W"
else BIGEST_DIM="H"
fi
if [ "${BIGEST_DIM}" == "W" ]; then
size_ratio "${WIDTH_ORIG}" "${4}"
else size_ratio "${HEIGHT_ORIG}" "${4}"
fi
NEW_WIDTH=`echo ${WIDTH_ORIG} / ${SIZE_RATIO} | bc -l | cut -d. -f1`
NEW_HEIGHT=`echo ${HEIGHT_ORIG} / ${SIZE_RATIO} | bc -l | cut -d. -f1`
echo "Converting ${i} to `basename "${i}" .${1}`_web.${2} with a size of ${NEW_WIDTH}x${NEW_HEIGHT} pixels and a quality factor of ${3}..."
convert "${i}" -resize "${NEW_WIDTH}x${NEW_HEIGHT}" -quality "${3}" "`basename "${i}" .${1}`_web.${2}"
done
echo "Done!"
Pour le format de fichier, j’en reste aussi au jpeg, qui passe partout. Pour ce qui est de la taille, j’essaie de la minimiser sans pour autant nuire à l’esthétique ou à la présentation souhaitée, mais en préférant des images cliquables (cliquez pour agrandir) aux grandes partout où c’est possible. Et j’adapte la taille à l’écran (faire un CSS “responsive”). Donc, chaque image est choisie en fonction de la résolution d’écran de l’internaute, qui peut éventuellement choisir de l’agrandir. La bande passante est ainsi réduite au strict nécessaire compte tenu de la taille d’écran, et l’image en taille maximale (qui peut être de plusieurs dizaines de mégapixels !) n’est envoyée que sur demande expresse de l’internaute.
Il est bien dans ce dernier cas d’afficher la taille de l’image à télécharger (utiliser le “title” de la balise par exemple). Éventuellement, on peut prévoir le téléchargement de plusieurs tailles, en fonction de la taille d’écran ou en laissant le choix à l’internaute.
Bon, je réalise que ta question concernait Framasite… Je ne sais pas si ma réponse est bien adaptée, ne l’utilisant pas ! Mais bon, si Framasite ne permet pas de faire ce que je propose, c’est bien dommage. Ça devrait quand même être possible en écrivant un peu de HTML et de CSS.
Mon site en construction va me servir principalement pour présenter ma musique, des textes et des activités en rapport. Les images seront juste des illustrations de ces activités, donc je n’ai pas vraiment besoin quelles soient en haute définition.
Pour le CSS, il est possible d’importer les feuilles de style proposées par framasite, et il me semble aussi de les éditer mais je n’ai pas encore essayé. J’ai essayé de mettre des balises php dans une page, ça semble fonctionner. Quand au html, je n’ai pas encore essayé.
Jusqu’à présent, j’aime bien le soft qui gère le site. Il a de bonnes fonctions et est relativement simple à utiliser. En comparaison wordpress est un monstre hyper complexe où rien que pour savoir quel plugin utiliser pour faire un truc, il faut être programmeur web à plein temps.
Oui, en règle générale, je déteste les CMS : le temps qu’on apprenne à s’en servir et qu’on passe ensuite à galérer avec ces usines à gaz, on a largement 10 fois le temps d’acquérir les connaissances et l’expérience nécessaires à faire de très belles choses en HTML/CSS avec un peu de PHP !
Bon, j’espère que framasite ne tombe pas dans ces travers, mais bon, HTML a quand même été conçu pour que les scientifiques du CERN puissent facilement s’échanger des documents et rapports… Ils ont autre chose à faire que s’em*** avec des usines à gaz. Un langage à balises est fait pour le grand public, ce n’est pas un langage informatique !
Il y avait une règle autrefois, parmi les hackers (les vrais, pas les crackers !), quelques règles qu’ils s’efforçaient de suivre :
On fait une chose, et on la fait bien
Un logiciel doit être stable (et donc, ne pas changer d’interface tous les trois mois !)
Le code doit être libre (renié, hélas, par ESR, auteur du texte donné en lien ci-dessus et initiateur du mouvement OpenSource, qui n’a rien à voir avec le logiciel libre)
La présentation doit être claire, précise et donner accès à toutes les fonctionnalités
etc.
La mode (je dirais même la règle absolue, inviolable, incontestée et considérée comme incontestable) actuelle est de faire exactement l’inverse et d’alimenter ainsi grassement la loi de Wirth (appelée parfois, à mon grand amusement, la loi de Gates)
Une des raisons qui font que mon bureau préféré sous linux est fvwm-crystal est qu’il est un ensemble de thèmes pour fvwm et que fwvm change très lentement. Je n’ai jamais perdu une seule préférence du bureau ni une seule modif du menu des applications, lequel cerise sur le gâteau, supporte même les catégories additionnelles de la spécification de FreeDesktop (une sacrée usine à gaz cette norme car elle est complètement redondante entre les fichiers fournis par les programmes et ceux fournis par les bureaux, fvwm-crystal n’utilise que les fichiers fournis par les applications pour créer son menu et ça marche super bien…).
