Author: kent1@arscenic.info
Date: 2009-03-08 18:48:27 +0100 (dim, 08 mar 2009)
New Revision: 13816
Log:
Un pipeline "post_ecrire_image" qui suit l'écriture d'une image dans le cache permettant de faire des post traitements automatiques ...
Modified:
spip/ecrire/inc/filtres_images_lib_mini.php
Hello,
2 remarques :
- le pipeline pourrait recevoir tout le tableau $valeurs qui contient toutes les infos sur l'image
- a quel type de post-traitement pense tu ? Je dirais a première vue que ça ne peut être que du passif qui ne modifie pas l'image produite
Si tu penses à un post-traitement intrusif qui modifie l'image produite, alors ce n'est pas compatible avec la destruction automatique des images intermédiaires.
Autrement dit, si c'est une image intermédiaire, celle-ci sera supprimée à la fin des traitements, mais en cas de besoin elle sera re-générée, sans les modifs de ton post-traitement.
En résumé, j'ai peur que ce pipeline ne donne de mauvaises idées et fasse faire des choses qui ne marcheront pas ...
Cédric
Le 8 mars 09 à 18:48, kent1@arscenic.info a écrit :
Author: kent1@arscenic.info
Date: 2009-03-08 18:48:27 +0100 (dim, 08 mar 2009)
New Revision: 13816Log:
Un pipeline "post_ecrire_image" qui suit l'écriture d'une image dans le cache permettant de faire des post traitements automatiques ...Modified:
spip/ecrire/inc/filtres_images_lib_mini.phpDetails: http://trac.rezo.net/trac/spip/changeset/13816
_______________________________________________
spip-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
Hello,
lo ...
2 remarques :
je prends...
- le pipeline pourrait recevoir tout le tableau $valeurs qui contient
toutes les infos sur l'image
oui effectivement
- a quel type de post-traitement pense tu ? Je dirais a première vue que ça
ne peut être que du passif qui ne modifie pas l'image produite
En gros ... c'est en vue d'utiliser un plugin particulier dans l'instant ...
plugin basé sur l'api de http://smush.it que je commites dans quelques
heures... qui fonctionne en gros comme ca :
après le traitement des filtre image (et que le fichier soit écrit) on
envoit cette image au site par l'intermédiaire de son api ... celui nous
renvoit un json qui nous indique si l'image est optimisable ... si oui le
plugin remplace l'image sortie des filtres image par l'image optimisée
récupérée sur smush.it.
à mon avis c'est le moyen le plus simple pour avoir constamment des images
optimisées à fond sans se prendre la tête plus que cela...
Si tu penses à un post-traitement intrusif qui modifie l'image produite,
alors ce n'est pas compatible avec la destruction automatique des images
intermédiaires.
Autrement dit, si c'est une image intermédiaire, celle-ci sera supprimée à
la fin des traitements, mais en cas de besoin elle sera re-générée, sans les
modifs de ton post-traitement.
hmm ok...
J'ai un peu de mal à appréhender l'ensemble du processus de génération des
images...
Si tu as une meilleure idée...
Je pense qu'éviter de passer par l'ajout d'un filtre dans les squelettes est
primordial pour ce plugin ... mais peut être me trompes-je?
En résumé, j'ai peur que ce pipeline ne donne de mauvaises idées et fasse
faire des choses qui ne marcheront pas ...
Voila mes explications .... si tu trouves toujours que c'est une mauvaise
idée ... je le vire sans problème... j'ai juste mis ca dans la branche dev
pour sortir le plugin et avoir des retours 
Cédric
Q.
Le 8 mars 09 à 18:48, kent1@arscenic.info a écrit :
Author: kent1@arscenic.info
Date: 2009-03-08 18:48:27 +0100 (dim, 08 mar 2009)
New Revision: 13816Log:
Un pipeline "post_ecrire_image" qui suit l'écriture d'une image dans le
cache permettant de faire des post traitements automatiques ...Modified:
spip/ecrire/inc/filtres_images_lib_mini.phpDetails: http://trac.rezo.net/trac/spip/changeset/13816
_______________________________________________
spip-commit@rezo.net -
http://listes.rezo.net/mailman/listinfo/spip-commit
dev: http://trac.rezo.net/trac/spip/
Quentin Drouet a écrit :
...
- le pipeline pourrait recevoir tout le tableau $valeurs qui contient
toutes les infos sur l'image
oui effectivement- a quel type de post-traitement pense tu ? Je dirais a première vue que ça
ne peut être que du passif qui ne modifie pas l'image produite
En gros ... c'est en vue d'utiliser un plugin particulier dans l'instant ...
plugin basé sur l'api de http://smush.it que je commites dans quelques
heures... qui fonctionne en gros comme ca :après le traitement des filtre image (et que le fichier soit écrit) on
envoit cette image au site par l'intermédiaire de son api ... celui nous
renvoit un json qui nous indique si l'image est optimisable ... si oui le
plugin remplace l'image sortie des filtres image par l'image optimisée
récupérée sur smush.it.à mon avis c'est le moyen le plus simple pour avoir constamment des images
optimisées à fond sans se prendre la tête plus que cela...Si tu penses à un post-traitement intrusif qui modifie l'image produite,
alors ce n'est pas compatible avec la destruction automatique des images
intermédiaires.
Autrement dit, si c'est une image intermédiaire, celle-ci sera supprimée à
la fin des traitements, mais en cas de besoin elle sera re-générée, sans les
modifs de ton post-traitement.
hmm ok...J'ai un peu de mal à appréhender l'ensemble du processus de génération des
images...
Si tu as une meilleure idée...Je pense qu'éviter de passer par l'ajout d'un filtre dans les squelettes est
primordial pour ce plugin ... mais peut être me trompes-je?
je crois que le mieux serait :
- d'ecrire la fonction qui smush ou autre comme les autres filtres images, pour qu'elle beneficie du cache (eviter de smusher 10 fois la meme image avec autant d'appel au serveur)
- d'introduire un pipeline à l'entrée de image_graver qui est ajoutée par le compilateur à chaque fin de serie de calcul d'images, avec une syntaxe du type
function image_graver($img){
$img = pipeline('image_post_process',$img);
...
}
Ainsi seules les images finales, conservées seront smushées et d'autre part le smush sera mis en cache également (ie seule l'image finale optimisée sera conservée in fine).
Cédric
cedric.morin@yterium.com a écrit :
Quentin Drouet a écrit :
...
je crois que le mieux serait :
- d'ecrire la fonction qui smush ou autre comme les autres filtres images, pour qu'elle beneficie du cache (eviter de smusher 10 fois la meme image avec autant d'appel au serveur)
- d'introduire un pipeline à l'entrée de image_graver qui est ajoutée par le compilateur à chaque fin de serie de calcul d'images, avec une syntaxe du type
function image_graver($img){
$img = pipeline('image_post_process',$img);
...
}
cedric.morin@yterium.com a écrit :
Quentin Drouet a écrit :
...
je crois que le mieux serait :
- d'ecrire la fonction qui smush ou autre comme les autres filtres images,
pour qu'elle beneficie du cache (eviter de smusher 10 fois la meme image
avec autant d'appel au serveur)
- d'introduire un pipeline à l'entrée de image_graver qui est ajoutée par
le compilateur à chaque fin de serie de calcul d'images, avec une syntaxe du
type
function image_graver($img){
$img = pipeline('image_post_process',$img);
...
}
merci ...
Q.
--
-----
Arscenic - Luxembourg asbl
Promotion et diffusion des Arts Numériques et des Nouvelles Scénographies
5, rue de la montagne
L-4879 Lamadelaine
Luxembourg
http://www.aires-de-confluxence.info - http://www.sklunk.net
tél : +33 (0)616706301
mail: quentin@arscenic.info
à mon avis c'est le moyen le plus simple pour avoir constamment des images
optimisées à fond sans se prendre la tête plus que cela...
Je pense qu'éviter de passer par l'ajout d'un filtre dans les squelettes est
primordial pour ce plugin ... mais peut être me trompes-je?
Et si on ne veut "smusher" que certaines images ? Notamment, je suppose que cela retire les données EXIF, ce que l'on ne veut pas forcément sur des photos...
-Nicolas
--
Nicolas HOIZEY
Nicolas Hoizey a écrit :
à mon avis c'est le moyen le plus simple pour avoir constamment des images
optimisées à fond sans se prendre la tête plus que cela...
Je pense qu'éviter de passer par l'ajout d'un filtre dans les squelettes est
primordial pour ce plugin ... mais peut être me trompes-je?Et si on ne veut "smusher" que certaines images ? Notamment, je suppose que cela retire les données EXIF, ce que l'on ne veut pas forcément sur des photos...
ca ne smushera que les images qui sortent d'un filtre image_xx, dont qui n'ont deja plus d'exif, par exemple.
Cédric
Le 8 mars 09 à 22:27, cedric.morin@yterium.com a écrit :
Nicolas Hoizey a écrit :
à mon avis c'est le moyen le plus simple pour avoir constamment des images
optimisées à fond sans se prendre la tête plus que cela...
Je pense qu'éviter de passer par l'ajout d'un filtre dans les squelettes est
primordial pour ce plugin ... mais peut être me trompes-je?Et si on ne veut "smusher" que certaines images ? Notamment, je suppose que cela retire les données EXIF, ce que l'on ne veut pas forcément sur des photos...
ca ne smushera que les images qui sortent d'un filtre image_xx, dont qui n'ont deja plus d'exif, par exemple.
Ah bon, ces filtres virent les EXIF de toute façon ???
-Nicolas
--
Nicolas HOIZEY
2009/3/8 Nicolas Hoizey <nicolas@hoizey.com>
De mon point de vue, même si on présente une photo en taille réduite parce
qu'en taille réelle ce serait inexploitable sur le Web, on peut vouloir
laisser les EXIF pour donner à voir les paramètres de prise de vue, dont la
photo (et non sa taille) dépend.
Donc avant de s'évertuer à papotter sur quelque chose qui n'existe pas ...
un exemple simple télécharge ces 2 images :
- l'originale : http://kent1.sklunk.net/IMG/jpg/IMG_1382.jpg
- la version resizée par spip (en 2.0 mais c'était pareil auparavant) :
http://kent1.sklunk.net/local/cache-vignettes/L500xH375/IMG_1382-7314f.jpg
Il n'y a qu'un simple image_reduire sur ces images ... pas de smush_it ou
autre ...
Ouvres ces 2 images dans un vrai logiciel d'image type Aperture ou autre ...
Regarde la partie exif ....
et tu verras la différence ...
Donc si on smush l'image, on va encore gagner sur le poids de l'image (au
moins 20%) ... mais ce qu'on va perdre ... va être quand même limité ...
Par contre ... le nouveau pipeline mis en place par Cédric va t'être très
utile ... puisque du coup tu vas pouvoir coder un chouette plugin qui va s'y
insérer et récupérer les exifs de l'image d'origine et les remettre sur
l'image retaillée si tu les utilises...
Bref ... merci d'avance pour le futur plugin que tu vas apporter à la
communauté 
++
Q.
Le 8 mars 09 à 22:29, Quentin Drouet a écrit :
2009/3/8 Nicolas Hoizey <nicolas@hoizey.com>
à mon avis c'est le moyen le plus simple pour avoir constamment des
images
optimisées à fond sans se prendre la tête plus que cela...
Je pense qu'éviter de passer par l'ajout d'un filtre dans les squelettes
est
primordial pour ce plugin ... mais peut être me trompes-je?Et si on ne veut "smusher" que certaines images ? Notamment, je suppose
que cela retire les données EXIF, ce que l'on ne veut pas forcément sur des
photos...Copié coller d'IRC y'a 2 sec :
[22:23]marcimat:hum... il a raison nicolas aussi
[22:23] BoOz a rejoint le canal.
[22:23]kent1:mais bon l'idée était d'optimiser aussi les vignettes des
documents
[22:23]marcimat:mais qui s'intéresse au EXIFs
[22:23]kent1:c'est pour ca que c'est juste sur les images produites par
spip marcimat
[22:24]marcimat:right join, ça m'étonnerait _fil_
[22:24]marcimat:bah, quand tu fais une boucle document que tu réduis à
|image_reduire{500}
[22:24]kent1:pas sur celles que tu uploadent qui restent originales
[22:24]marcimat:ça va passer dans le smush aussi ?
[22:24]kent1:ben oui
[22:24]kent1:mais les exifs disparaissent dans ce cas
[22:24]kent1:dès le départ...
[22:25]kent1:non?
[22:25]marcimat:ah ?
[22:25]marcimat:peut être, je sais pas
[22:26] artlogic a rejoint le canal.
[22:26]kent1:l'intérêt de garder les exifs n'est valable que sur les
images d'origine
[22:26]kent1:à mon sens
[22:26]kent1:après ca n'a plus de sens réel
[22:27]kent1:puisque ton image est modifiée et aucun exif ajouté dans le
process
[22:27]kent1:donc dans tous les cas ces exifs seront faux
[22:27]kent1:donc...
[22:27]kent1:
ne servent plus à rien-Nicolas
voila... ce que j'en pense
Q.-Nicolas
--
Nicolas HOIZEY
http://www.gasteroprod.com/
Le 9 mars 09 à 00:11, Quentin Drouet a écrit :
Donc avant de s'évertuer à papotter sur quelque chose qui n'existe pas ... un exemple simple télécharge ces 2 images :
- l'originale : http://kent1.sklunk.net/IMG/jpg/IMG_1382.jpg
- la version resizée par spip (en 2.0 mais c'était pareil auparavant) : http://kent1.sklunk.net/local/cache-vignettes/L500xH375/IMG_1382-7314f.jpg
Il n'y a qu'un simple image_reduire sur ces images ... pas de smush_it ou autre ...
Ah oui, donc ça craint... 
Donc si on smush l'image, on va encore gagner sur le poids de l'image (au moins 20%) ... mais ce qu'on va perdre ... va être quand même limité ...
Certes. Il faudrait donc à mon avis que la fonction qui redimensionne ne fasse que ça, et qu'on ait une fonction image_efface_meta() qui fasse le nettoyage des meta données, comme son nom l'indique.
Par contre ... le nouveau pipeline mis en place par Cédric va t'être très utile ... puisque du coup tu vas pouvoir coder un chouette plugin qui va s'y insérer et récupérer les exifs de l'image d'origine et les remettre sur l'image retaillée si tu les utilises...
Ouh la, compliqué, ça, ce serait à mon avis mieux que les fonctions fassent ce que leur nom (et doc) suppose, plutôt que devoir se triturer les méninge à ce point.
Bref ... merci d'avance pour le futur plugin que tu vas apporter à la communauté
J'essaie déjà de mettre à jour "liens_contenus", et on en reparle...
-Nicolas
--
Nicolas HOIZEY
