La majorité des programmes de traitement d'image produisent, quand on leur
demande une rotation de jpeg, un nouveau fichier dont la taille en Ko n'a
souvent plus rien à voir avec le jpeg original, il y a donc quelquepart
altération inutile de l'image originale.
Une image a taux de compression égal doit peser la même chose qu'elle soit
orientée dans le sens portrait ou paysage, c'est logique.
Pour tourner mes images, j'utilise "exifer", programme gratuit
http://www.exifer.friedemann.info/
et j'obtiens une image qui fait exactement le même poids.
J'utilise une fonction, vraiment "accessoire" d'un programme qui, par
ailleurs, fait pleins de chose dont je n'ai pas l'utilité.
Qu'utilisez vous pour la rotation de JPEG?
A world without walls needs neither Windows nor Gates
TU peux mettre en ligne un ou deux images avant et après qu'on puisse voir ce que ça donne ?
je ne comprends pas le sens de ta demande.
le fait que je mette en ligne un fichier exemple ne te donnera pas la vitesse du traitement de la ré-orientation...
Je voudrais voir le temps que je mets à le faire moi. Et comparer les fichiers.
Peut-être refaire les rotation sur un PC d'un copain ?
Ceci dit je ne comprends pas moi que ça te dérranges...
Voilà.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
"Alf92" <alf92[NO-SPAM]@freesurf.fr> writes:
FiLH a dit ça :
TU peux mettre en ligne un ou deux images avant et après qu'on puisse
voir ce que ça donne ?
je ne comprends pas le sens de ta demande.
le fait que je mette en ligne un fichier exemple ne te donnera pas la
vitesse du traitement de la ré-orientation...
Je voudrais voir le temps que je mets à le faire moi.
Et comparer les fichiers.
Peut-être refaire les rotation sur un PC d'un copain ?
Ceci dit je ne comprends pas moi que ça te dérranges...
Voilà.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
TU peux mettre en ligne un ou deux images avant et après qu'on puisse voir ce que ça donne ?
je ne comprends pas le sens de ta demande.
le fait que je mette en ligne un fichier exemple ne te donnera pas la vitesse du traitement de la ré-orientation...
Je voudrais voir le temps que je mets à le faire moi. Et comparer les fichiers.
Peut-être refaire les rotation sur un PC d'un copain ?
Ceci dit je ne comprends pas moi que ça te dérranges...
Voilà.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Alf92
FiLH a dit ça :
comment fait-il pour savoir si la photo est dans le bon sens ? tu dois bien faire une selection manuelle pour indiquer l'orientation à retenir, non ?
Quel rapport peut-il bien y avoir entre cette question et le fait de modifier ou pas les fichiers originaux ?
Je me le demande.
le temps que cela prend. car au final, et d'après ce que tu disais hier soir, c'est cela qui compte pour toi. je te comprends, le temps c'est précieux.
mon propos est donc de tenter de te démontrer qu'il est plus avantageux en terme de temps de faire :
A/ une rotation définitive d'un JPG (le temps de sa selection et de son traitement)
plutot que :
B/ de laisser le fichier tel dans ton catalogueur, ce qui implique 1/ que tu lui ais initialement donné l'information d'orientation, 2/ qu'à chaque usage ultérieur de ton image tu ais à procéder à son retournement.
c'est plus clair comme ceci ? je reste à ta disposition pour tout renseignement complémentaire.
-- Cordialement, Alf92 http://frpn.free.fr
FiLH a dit ça :
comment fait-il pour savoir si la photo est dans le bon sens ?
tu dois bien faire une selection manuelle pour indiquer l'orientation
à retenir, non ?
Quel rapport peut-il bien y avoir entre cette question et le fait de
modifier ou pas les fichiers originaux ?
Je me le demande.
le temps que cela prend.
car au final, et d'après ce que tu disais hier soir, c'est cela qui compte
pour toi.
je te comprends, le temps c'est précieux.
mon propos est donc de tenter de te démontrer qu'il est plus avantageux en
terme de temps de faire :
A/ une rotation définitive d'un JPG (le temps de sa selection et de son
traitement)
plutot que :
B/ de laisser le fichier tel dans ton catalogueur, ce qui implique
1/ que tu lui ais initialement donné l'information d'orientation,
2/ qu'à chaque usage ultérieur de ton image tu ais à procéder à son
retournement.
c'est plus clair comme ceci ?
je reste à ta disposition pour tout renseignement complémentaire.
comment fait-il pour savoir si la photo est dans le bon sens ? tu dois bien faire une selection manuelle pour indiquer l'orientation à retenir, non ?
Quel rapport peut-il bien y avoir entre cette question et le fait de modifier ou pas les fichiers originaux ?
Je me le demande.
le temps que cela prend. car au final, et d'après ce que tu disais hier soir, c'est cela qui compte pour toi. je te comprends, le temps c'est précieux.
mon propos est donc de tenter de te démontrer qu'il est plus avantageux en terme de temps de faire :
A/ une rotation définitive d'un JPG (le temps de sa selection et de son traitement)
plutot que :
B/ de laisser le fichier tel dans ton catalogueur, ce qui implique 1/ que tu lui ais initialement donné l'information d'orientation, 2/ qu'à chaque usage ultérieur de ton image tu ais à procéder à son retournement.
c'est plus clair comme ceci ? je reste à ta disposition pour tout renseignement complémentaire.
-- Cordialement, Alf92 http://frpn.free.fr
Alf92
FiLH a dit ça :
"Alf92" <alf92[NO-SPAM]@freesurf.fr> writes:
FiLH a dit ça :
Je cherche juste à comprendre.
pour cela il faudrait d'abord que tu acceptes que les autres n'aient pas le même avis que toi.
Le chronométrage n'est pas une question d'avis.
Les chronomtrages contradictoires d'avec les tiens c'est même pas moi qui les ai faits.
Quand je vois 5 données convergeantes et une divergeante...
D'ailleurs je t'ai demandé si tu pouvais mettre une ou deux photos avant et après rotation en accés... et j'attends toujours.
je ne demande pas mieux, mais quel rapport entre mettre en ligne une image exemple et la véracité du chronométrage ? là il faudrait que tu m'expliques. merci d'avance.
-- Cordialement, Alf92 http://frpn.free.fr
FiLH a dit ça :
"Alf92" <alf92[NO-SPAM]@freesurf.fr> writes:
FiLH a dit ça :
Je cherche juste à comprendre.
pour cela il faudrait d'abord que tu acceptes que les autres n'aient
pas le même avis que toi.
Le chronométrage n'est pas une question d'avis.
Les chronomtrages contradictoires d'avec les tiens c'est même pas moi
qui les ai faits.
Quand je vois 5 données convergeantes et une divergeante...
D'ailleurs je t'ai demandé si tu pouvais mettre une ou deux photos
avant et après rotation en accés... et j'attends toujours.
je ne demande pas mieux, mais quel rapport entre mettre en ligne une image
exemple et la véracité du chronométrage ?
là il faudrait que tu m'expliques.
merci d'avance.
pour cela il faudrait d'abord que tu acceptes que les autres n'aient pas le même avis que toi.
Le chronométrage n'est pas une question d'avis.
Les chronomtrages contradictoires d'avec les tiens c'est même pas moi qui les ai faits.
Quand je vois 5 données convergeantes et une divergeante...
D'ailleurs je t'ai demandé si tu pouvais mettre une ou deux photos avant et après rotation en accés... et j'attends toujours.
je ne demande pas mieux, mais quel rapport entre mettre en ligne une image exemple et la véracité du chronométrage ? là il faudrait que tu m'expliques. merci d'avance.
-- Cordialement, Alf92 http://frpn.free.fr
JPW
"Denis Vanneste" a écrit
puisqu'il faut te mettre les points sur les i, sache que je t'emmerde.
mais je m'en tape mon beau denis
il n'est pas mauvais de faire cesser les agressions goudaliennes
si tu préfères le soutenir libre à toi...
jpw
"Denis Vanneste" <reply.to@not.invalid> a écrit
puisqu'il faut te mettre les points sur les i, sache que je t'emmerde.
mais je m'en tape mon beau denis
il n'est pas mauvais de faire cesser les agressions goudaliennes
puisqu'il faut te mettre les points sur les i, sache que je t'emmerde.
mais je m'en tape mon beau denis
il n'est pas mauvais de faire cesser les agressions goudaliennes
si tu préfères le soutenir libre à toi...
jpw
Alf92
FiLH a dit ça :
Je cherche juste à comprendre.
pour cela il faudrait d'abord que tu acceptes que les autres n'aient pas le même avis que toi.
Le chronométrage n'est pas une question d'avis.
Les chronomtrages contradictoires d'avec les tiens c'est même pas moi qui les ai faits.
Quand je vois 5 données convergeantes et une divergeante...
- JC Ghislain : Le temps est directement lié à la taille des images. Dans les labos, actuellement, on manipule principalement des images d'environ 1,5 MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5 MPixels et que je leur fais subir une rotation sans perte, les 78 images sont tournées en moins de 10 secondes.
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide. Sur un P4 1.8GHz
- Alf92 : 100 images sorties de mon Minolta (2048x1536 compression moyenne) rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque ext à 4200tr/mn. durée : 9,5s soit environ 0.1s par fichier.
Stp, FiLH peux tu me rapeller les autres mesures. merci d'avance.
pour cela il faudrait d'abord que tu acceptes que les autres n'aient
pas le même avis que toi.
Le chronométrage n'est pas une question d'avis.
Les chronomtrages contradictoires d'avec les tiens c'est même pas moi
qui les ai faits.
Quand je vois 5 données convergeantes et une divergeante...
- JC Ghislain :
Le temps est directement lié à la taille des images. Dans les labos,
actuellement, on manipule principalement des images d'environ 1,5
MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5
MPixels et que je leur fais subir une rotation sans perte, les 78 images
sont tournées en moins de 10 secondes.
- François Jouve :
Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers
un serveur NFS distant donc pas trop rapide.
Sur un P4 1.8GHz
- Alf92 :
100 images sorties de mon Minolta (2048x1536 compression moyenne)
rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque
ext à 4200tr/mn.
durée : 9,5s soit environ 0.1s par fichier.
Stp, FiLH peux tu me rapeller les autres mesures.
merci d'avance.
pour cela il faudrait d'abord que tu acceptes que les autres n'aient pas le même avis que toi.
Le chronométrage n'est pas une question d'avis.
Les chronomtrages contradictoires d'avec les tiens c'est même pas moi qui les ai faits.
Quand je vois 5 données convergeantes et une divergeante...
- JC Ghislain : Le temps est directement lié à la taille des images. Dans les labos, actuellement, on manipule principalement des images d'environ 1,5 MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5 MPixels et que je leur fais subir une rotation sans perte, les 78 images sont tournées en moins de 10 secondes.
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide. Sur un P4 1.8GHz
- Alf92 : 100 images sorties de mon Minolta (2048x1536 compression moyenne) rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque ext à 4200tr/mn. durée : 9,5s soit environ 0.1s par fichier.
Stp, FiLH peux tu me rapeller les autres mesures. merci d'avance.
et c'est ton Pana qui indique le sens de l'orientation (capteur) ? ou tu le fais manuellement dans ton catalogueur ?
Contrairement à certains autres appareils, le FZ10 n'a pas de capteur d'orientation. Donc la première fois que je visualise les photos dans le catalogueur, je sélectionne les photos à redresser puis je clique sur le bouton de rotation. L'orientation est alors enregistrée pour toutes les photos et prise en compte lors les visualisations ultérieures.
Sur mon iBook actuel (G4/1GHz), lors de la visualisation par iView des photos en taille "réelle", je ne vois aucune différence de temps d'affichage entre les photos réorientées et les autres (instantané dans les deux cas). Mais sur mon précédent (G3/500MHz), il y avait un petit délai lors de l'affichage des photos verticales, pas vraiment gênant mais nettement perceptible. Ce qui incite à penser que l'affichage d'une image JPEG dans une orientation différente de son orientation d'origine entraîne bien un travail plus important pour le processeur, même si ce travail supplémentaire passe inaperçu sur les machines récentes.
A++ -- Christian
"Alf92" <alf92[NO-SPAM]@freesurf.fr> wrote:
et c'est ton Pana qui indique le sens de l'orientation (capteur) ?
ou tu le fais manuellement dans ton catalogueur ?
Contrairement à certains autres appareils, le FZ10 n'a pas de capteur
d'orientation. Donc la première fois que je visualise les photos dans le
catalogueur, je sélectionne les photos à redresser puis je clique sur le
bouton de rotation. L'orientation est alors enregistrée pour toutes les
photos et prise en compte lors les visualisations ultérieures.
Sur mon iBook actuel (G4/1GHz), lors de la visualisation par iView des
photos en taille "réelle", je ne vois aucune différence de temps
d'affichage entre les photos réorientées et les autres (instantané dans
les deux cas). Mais sur mon précédent (G3/500MHz), il y avait un petit
délai lors de l'affichage des photos verticales, pas vraiment gênant
mais nettement perceptible. Ce qui incite à penser que l'affichage d'une
image JPEG dans une orientation différente de son orientation d'origine
entraîne bien un travail plus important pour le processeur, même si ce
travail supplémentaire passe inaperçu sur les machines récentes.
et c'est ton Pana qui indique le sens de l'orientation (capteur) ? ou tu le fais manuellement dans ton catalogueur ?
Contrairement à certains autres appareils, le FZ10 n'a pas de capteur d'orientation. Donc la première fois que je visualise les photos dans le catalogueur, je sélectionne les photos à redresser puis je clique sur le bouton de rotation. L'orientation est alors enregistrée pour toutes les photos et prise en compte lors les visualisations ultérieures.
Sur mon iBook actuel (G4/1GHz), lors de la visualisation par iView des photos en taille "réelle", je ne vois aucune différence de temps d'affichage entre les photos réorientées et les autres (instantané dans les deux cas). Mais sur mon précédent (G3/500MHz), il y avait un petit délai lors de l'affichage des photos verticales, pas vraiment gênant mais nettement perceptible. Ce qui incite à penser que l'affichage d'une image JPEG dans une orientation différente de son orientation d'origine entraîne bien un travail plus important pour le processeur, même si ce travail supplémentaire passe inaperçu sur les machines récentes.
A++ -- Christian
Denis Vanneste
il n'est pas mauvais de faire cesser les agressions goudaliennes
si tu préfères le soutenir libre à toi...
Réfléchis un peu, pépé. Du moins, essaie de réfléchir, avec le peu de jugeotte qu'il te reste. Si le simple fait de prendre part à une discussion à laquelle FiLH participe signifie qu'on le soutient, alors toi, on peut dire que tu n'arrêtes pas de le soutenir. À tel point que ça en devient suspect. Il te paie bien, au moins ?
-- Denis Vanneste
il n'est pas mauvais de faire cesser les agressions goudaliennes
si tu préfères le soutenir libre à toi...
Réfléchis un peu, pépé. Du moins, essaie de réfléchir, avec le peu de
jugeotte qu'il te reste. Si le simple fait de prendre part à une
discussion à laquelle FiLH participe signifie qu'on le soutient, alors
toi, on peut dire que tu n'arrêtes pas de le soutenir. À tel point que
ça en devient suspect. Il te paie bien, au moins ?
il n'est pas mauvais de faire cesser les agressions goudaliennes
si tu préfères le soutenir libre à toi...
Réfléchis un peu, pépé. Du moins, essaie de réfléchir, avec le peu de jugeotte qu'il te reste. Si le simple fait de prendre part à une discussion à laquelle FiLH participe signifie qu'on le soutient, alors toi, on peut dire que tu n'arrêtes pas de le soutenir. À tel point que ça en devient suspect. Il te paie bien, au moins ?
-- Denis Vanneste
filh
"Alf92" <alf92[NO-SPAM]@freesurf.fr> wrote:
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide.
Non, il s'agit d'une erreur que j'ai corrigé le temps utilisateur est le temps de calcul, le temps noté s est le temps système qui est le temps passé en mode noyau.
Le temps de calcul est donc de 0,67s et 0.09 passé en exécution noyau.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
"Alf92" <alf92[NO-SPAM]@freesurf.fr> wrote:
- François Jouve :
Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers
un serveur NFS distant donc pas trop rapide.
Non, il s'agit d'une erreur que j'ai corrigé le temps utilisateur est le
temps de calcul, le temps noté s est le temps système qui est le temps
passé en mode noyau.
Le temps de calcul est donc de 0,67s et 0.09 passé en exécution noyau.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide.
Non, il s'agit d'une erreur que j'ai corrigé le temps utilisateur est le temps de calcul, le temps noté s est le temps système qui est le temps passé en mode noyau.
Le temps de calcul est donc de 0,67s et 0.09 passé en exécution noyau.
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
François Jouve
Alf92 wrote:
- JC Ghislain : Le temps est directement lié à la taille des images. Dans les labos, actuellement, on manipule principalement des images d'environ 1,5 MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5 MPixels et que je leur fais subir une rotation sans perte, les 78 images sont tournées en moins de 10 secondes.
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide. Sur un P4 1.8GHz
- Alf92 : 100 images sorties de mon Minolta (2048x1536 compression moyenne) rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque ext à 4200tr/mn. durée : 9,5s soit environ 0.1s par fichier.
Sans vouloir interferer dans vos querelles de bar, mon timing (qui était faux tel qu'il est ci-dessus, il faut comprendre 0.67s de calcul et 0.09 de temps annexe), se rapportait à l'image de JCG qui faisait 3000x2000. De plus c'était sur un P4 2.6GHz (promis, je n'avais rien bu :) )
Pour une image de 3Mpixels je trouve sur la meme becane: 0.160u 0.050s 0:00.21 100.0% 0+0k 0+0io 113pf+0w soit 0.16s de calcul et 0.21s tout compris.
-- F.J.
Alf92 wrote:
- JC Ghislain :
Le temps est directement lié à la taille des images. Dans les labos,
actuellement, on manipule principalement des images d'environ 1,5
MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5
MPixels et que je leur fais subir une rotation sans perte, les 78 images
sont tournées en moins de 10 secondes.
- François Jouve :
Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers
un serveur NFS distant donc pas trop rapide.
Sur un P4 1.8GHz
- Alf92 :
100 images sorties de mon Minolta (2048x1536 compression moyenne)
rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque
ext à 4200tr/mn.
durée : 9,5s soit environ 0.1s par fichier.
Sans vouloir interferer dans vos querelles de bar, mon timing
(qui était faux tel qu'il est ci-dessus, il faut comprendre
0.67s de calcul et 0.09 de temps annexe), se rapportait
à l'image de JCG qui faisait 3000x2000. De plus c'était sur un P4 2.6GHz
(promis, je n'avais rien bu :) )
Pour une image de 3Mpixels je trouve sur la meme becane:
0.160u 0.050s 0:00.21 100.0% 0+0k 0+0io 113pf+0w
soit 0.16s de calcul et 0.21s tout compris.
- JC Ghislain : Le temps est directement lié à la taille des images. Dans les labos, actuellement, on manipule principalement des images d'environ 1,5 MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5 MPixels et que je leur fais subir une rotation sans perte, les 78 images sont tournées en moins de 10 secondes.
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide. Sur un P4 1.8GHz
- Alf92 : 100 images sorties de mon Minolta (2048x1536 compression moyenne) rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque ext à 4200tr/mn. durée : 9,5s soit environ 0.1s par fichier.
Sans vouloir interferer dans vos querelles de bar, mon timing (qui était faux tel qu'il est ci-dessus, il faut comprendre 0.67s de calcul et 0.09 de temps annexe), se rapportait à l'image de JCG qui faisait 3000x2000. De plus c'était sur un P4 2.6GHz (promis, je n'avais rien bu :) )
Pour une image de 3Mpixels je trouve sur la meme becane: 0.160u 0.050s 0:00.21 100.0% 0+0k 0+0io 113pf+0w soit 0.16s de calcul et 0.21s tout compris.
-- F.J.
filh
François Jouve wrote:
Alf92 wrote:
- JC Ghislain : Le temps est directement lié à la taille des images. Dans les labos, actuellement, on manipule principalement des images d'environ 1,5 MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5 MPixels et que je leur fais subir une rotation sans perte, les 78 images sont tournées en moins de 10 secondes.
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide. Sur un P4 1.8GHz
- Alf92 : 100 images sorties de mon Minolta (2048x1536 compression moyenne) rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque ext à 4200tr/mn. durée : 9,5s soit environ 0.1s par fichier.
Sans vouloir interferer dans vos querelles de bar, mon timing (qui était faux tel qu'il est ci-dessus, il faut comprendre 0.67s de calcul et 0.09 de temps annexe), se rapportait à l'image de JCG qui faisait 3000x20
Merci de confirmer ce que je disais sur l'inversion d'interprétation. Je pense j'aurais eu du mal à convaincre alf. En fait c'est 0.67s de calcul dont 0.09 de « system overhead » dixit les divers manuels unix.
Pour une image de 3Mpixels je trouve sur la meme becane: 0.160u 0.050s 0:00.21 100.0% 0+0k 0+0io 113pf+0w soit 0.16s de calcul et 0.21s tout compris.
T'est quand même à deux fois le temps de Alf... :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
François Jouve <Francois.Jouve_HALTEAUSPAM@Polytechnique.fr> wrote:
Alf92 wrote:
- JC Ghislain :
Le temps est directement lié à la taille des images. Dans les labos,
actuellement, on manipule principalement des images d'environ 1,5
MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5
MPixels et que je leur fais subir une rotation sans perte, les 78 images
sont tournées en moins de 10 secondes.
- François Jouve :
Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers
un serveur NFS distant donc pas trop rapide.
Sur un P4 1.8GHz
- Alf92 :
100 images sorties de mon Minolta (2048x1536 compression moyenne)
rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque
ext à 4200tr/mn.
durée : 9,5s soit environ 0.1s par fichier.
Sans vouloir interferer dans vos querelles de bar, mon timing
(qui était faux tel qu'il est ci-dessus, il faut comprendre
0.67s de calcul et 0.09 de temps annexe), se rapportait
à l'image de JCG qui faisait 3000x20
Merci de confirmer ce que je disais sur l'inversion d'interprétation. Je
pense j'aurais eu du mal à convaincre alf. En fait c'est 0.67s de calcul
dont 0.09 de « system overhead » dixit les divers manuels unix.
Pour une image de 3Mpixels je trouve sur la meme becane:
0.160u 0.050s 0:00.21 100.0% 0+0k 0+0io 113pf+0w
soit 0.16s de calcul et 0.21s tout compris.
T'est quand même à deux fois le temps de Alf... :)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
- JC Ghislain : Le temps est directement lié à la taille des images. Dans les labos, actuellement, on manipule principalement des images d'environ 1,5 MPixels. Si je reprends mes santons d'hier, que je les rapetisse à 1,5 MPixels et que je leur fais subir une rotation sans perte, les 78 images sont tournées en moins de 10 secondes.
- François Jouve : Soit en gros 0.09s de calcul et 0.67s d'entrée/sortie à travers un serveur NFS distant donc pas trop rapide. Sur un P4 1.8GHz
- Alf92 : 100 images sorties de mon Minolta (2048x1536 compression moyenne) rotation de 90° sur la gauche avec ACDSee 3 sur un celeron 2400 et un disque ext à 4200tr/mn. durée : 9,5s soit environ 0.1s par fichier.
Sans vouloir interferer dans vos querelles de bar, mon timing (qui était faux tel qu'il est ci-dessus, il faut comprendre 0.67s de calcul et 0.09 de temps annexe), se rapportait à l'image de JCG qui faisait 3000x20
Merci de confirmer ce que je disais sur l'inversion d'interprétation. Je pense j'aurais eu du mal à convaincre alf. En fait c'est 0.67s de calcul dont 0.09 de « system overhead » dixit les divers manuels unix.
Pour une image de 3Mpixels je trouve sur la meme becane: 0.160u 0.050s 0:00.21 100.0% 0+0k 0+0io 113pf+0w soit 0.16s de calcul et 0.21s tout compris.
T'est quand même à deux fois le temps de Alf... :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
