Bonjour !
J'ai besoin de gérer des images avec php ! Mais malgré mes recherches plutôt
poussées je n'ai pas encore trouvé la fonction adéquate !
J'ai besoin de pouvoir obtenir le dpi d'une image par le biais de php !
Pour cela il me faut
- Soit une fonction le fessant directement
- Soit une fonction me donnant sa taille en pixel et sa taille dans un
système métrique !
Quelqu'un aurai une solution pour moi ?
Peu être une librairie php ?
Une image n'a pas de dpi! Les dpi n'ont un sens que lors de l'impression. Tant que tu n'imprimes pas la photo, sa taille s'exprime en pixels.
Bin en général, une image a pour but d'être visualisée. Soit on l'imprime sur du papier via une imprimante, soit on imprime sur un écran via un moniteur. Il soit y avoir d'autres usages moins courant, mais ces deux cas usuels passe par une impression.
-- Khanh-Dang, élève de MPSI qui ne devrait pas être sur Usenet http://kd.fr.st/
Gg a écrit :
Une image n'a pas de dpi! Les dpi n'ont un sens que lors de
l'impression. Tant que tu n'imprimes pas la photo, sa taille s'exprime
en pixels.
Bin en général, une image a pour but d'être visualisée. Soit on
l'imprime sur du papier via une imprimante, soit on imprime sur un écran
via un moniteur. Il soit y avoir d'autres usages moins courant, mais ces
deux cas usuels passe par une impression.
--
Khanh-Dang, élève de MPSI qui ne devrait pas être sur Usenet
http://kd.fr.st/
Une image n'a pas de dpi! Les dpi n'ont un sens que lors de l'impression. Tant que tu n'imprimes pas la photo, sa taille s'exprime en pixels.
Bin en général, une image a pour but d'être visualisée. Soit on l'imprime sur du papier via une imprimante, soit on imprime sur un écran via un moniteur. Il soit y avoir d'autres usages moins courant, mais ces deux cas usuels passe par une impression.
-- Khanh-Dang, élève de MPSI qui ne devrait pas être sur Usenet http://kd.fr.st/
Thibaut Allender
on 3/05/2004 22:14, Khanh-Dang wrote :
Bin en général, une image a pour but d'être visualisée. Soit on l'imprime sur du papier via une imprimante, soit on imprime sur un écran via un moniteur. Il soit y avoir d'autres usages moins courant, mais ces deux cas usuels passe par une impression.
c'est vrai, mais l'unité de mesure d'une image "imprimee" sur un ecran reste dans la plupart des cas le pixel, donc inutile de parler de dpi ici
Bin en général, une image a pour but d'être visualisée. Soit on
l'imprime sur du papier via une imprimante, soit on imprime sur un écran
via un moniteur. Il soit y avoir d'autres usages moins courant, mais ces
deux cas usuels passe par une impression.
c'est vrai, mais l'unité de mesure d'une image "imprimee" sur un ecran
reste dans la plupart des cas le pixel, donc inutile de parler de dpi ici
Bin en général, une image a pour but d'être visualisée. Soit on l'imprime sur du papier via une imprimante, soit on imprime sur un écran via un moniteur. Il soit y avoir d'autres usages moins courant, mais ces deux cas usuels passe par une impression.
c'est vrai, mais l'unité de mesure d'une image "imprimee" sur un ecran reste dans la plupart des cas le pixel, donc inutile de parler de dpi ici
c'est vrai, mais l'unité de mesure d'une image "imprimee" sur un ecran reste dans la plupart des cas le pixel, donc inutile de parler de dpi ici
Si tu as une image de 4800x4800 pixels (qui selon toi est carrée), la résolution horizontale étant de 2400 pixels par pouce et la résolution verticale 4800 pixels par pouce (ces résolutions différentes sur les deux axes se retrouvent sur certains scanners), tu auras bel et bien une image qui devrait être affichée avec des dimensions de 2x1 pouces (c'est un rectangle).
Presque personne ne ~devrait~ compter en pixels à part le système de fenêtrage peut-être. Je m'explique
Même dans un site, les tailles de polices de caractères ou d'images (c'est vrai que pour les images, la technologie est encore limitée, mais pourquoi pas utiliser du SVG pour les dessins vectoriels par exemple) ne devraient pas être spécifiés en pixels. En effet, une marge de 30 pixels pourra en réalité être représentée par une marge de 1 cm sur certains moniteurs mais 0.00001 cm sur d'autres (c'est pas moi qui ai payé pour ce moniteur aussi, c'est vrai ;) De plus, il existe des écrans qui ont des pixels non carrés mais rectangulaires. Cela voudrait dire qu'une image de 100x100 pixels serait vue comme un rectangle et non pas comme un carré comme le voudrait la plupart des webmasters.
C'est pourquoi de toute façon, il vaut mieux utiliser comme unité de longueur dans les feuilles de styles CSS l'"em" et non le "px".
-- Khanh-Dang, élève de MPSI qui ne devrait pas être sur Usenet http://kd.fr.st/
Thibaut Allender a écrit :
c'est vrai, mais l'unité de mesure d'une image "imprimee" sur un ecran
reste dans la plupart des cas le pixel, donc inutile de parler de dpi ici
Si tu as une image de 4800x4800 pixels (qui selon toi est carrée), la
résolution horizontale étant de 2400 pixels par pouce et la résolution
verticale 4800 pixels par pouce (ces résolutions différentes sur les
deux axes se retrouvent sur certains scanners), tu auras bel et bien une
image qui devrait être affichée avec des dimensions de 2x1 pouces (c'est
un rectangle).
Presque personne ne ~devrait~ compter en pixels à part le système de
fenêtrage peut-être. Je m'explique
Même dans un site, les tailles de polices de caractères ou d'images
(c'est vrai que pour les images, la technologie est encore limitée, mais
pourquoi pas utiliser du SVG pour les dessins vectoriels par exemple) ne
devraient pas être spécifiés en pixels.
En effet, une marge de 30 pixels pourra en réalité être représentée par
une marge de 1 cm sur certains moniteurs mais 0.00001 cm sur d'autres
(c'est pas moi qui ai payé pour ce moniteur aussi, c'est vrai ;)
De plus, il existe des écrans qui ont des pixels non carrés mais
rectangulaires. Cela voudrait dire qu'une image de 100x100 pixels serait
vue comme un rectangle et non pas comme un carré comme le voudrait la
plupart des webmasters.
C'est pourquoi de toute façon, il vaut mieux utiliser comme unité de
longueur dans les feuilles de styles CSS l'"em" et non le "px".
--
Khanh-Dang, élève de MPSI qui ne devrait pas être sur Usenet
http://kd.fr.st/
c'est vrai, mais l'unité de mesure d'une image "imprimee" sur un ecran reste dans la plupart des cas le pixel, donc inutile de parler de dpi ici
Si tu as une image de 4800x4800 pixels (qui selon toi est carrée), la résolution horizontale étant de 2400 pixels par pouce et la résolution verticale 4800 pixels par pouce (ces résolutions différentes sur les deux axes se retrouvent sur certains scanners), tu auras bel et bien une image qui devrait être affichée avec des dimensions de 2x1 pouces (c'est un rectangle).
Presque personne ne ~devrait~ compter en pixels à part le système de fenêtrage peut-être. Je m'explique
Même dans un site, les tailles de polices de caractères ou d'images (c'est vrai que pour les images, la technologie est encore limitée, mais pourquoi pas utiliser du SVG pour les dessins vectoriels par exemple) ne devraient pas être spécifiés en pixels. En effet, une marge de 30 pixels pourra en réalité être représentée par une marge de 1 cm sur certains moniteurs mais 0.00001 cm sur d'autres (c'est pas moi qui ai payé pour ce moniteur aussi, c'est vrai ;) De plus, il existe des écrans qui ont des pixels non carrés mais rectangulaires. Cela voudrait dire qu'une image de 100x100 pixels serait vue comme un rectangle et non pas comme un carré comme le voudrait la plupart des webmasters.
C'est pourquoi de toute façon, il vaut mieux utiliser comme unité de longueur dans les feuilles de styles CSS l'"em" et non le "px".
-- Khanh-Dang, élève de MPSI qui ne devrait pas être sur Usenet http://kd.fr.st/
Thibaut Allender
on 3/05/2004 23:36, Khanh-Dang wrote :
Si tu as une image de 4800x4800 pixels (qui selon toi est carrée), la résolution horizontale étant de 2400 pixels par pouce et la résolution verticale 4800 pixels par pouce (ces résolutions différentes sur les deux axes se retrouvent sur certains scanners), tu auras bel et bien une image qui devrait être affichée avec des dimensions de 2x1 pouces (c'est un rectangle).
mais quel logiciel gere une resolution differente sur les 2 axes ?
Même dans un site, les tailles de polices de caractères ou d'images (c'est vrai que pour les images, la technologie est encore limitée, mais pourquoi pas utiliser du SVG pour les dessins vectoriels par exemple) ne devraient pas être spécifiés en pixels. En effet, une marge de 30 pixels pourra en réalité être représentée par une marge de 1 cm sur certains moniteurs mais 0.00001 cm sur d'autres (c'est pas moi qui ai payé pour ce moniteur aussi, c'est vrai ;)
j'ai bien dit "dans la plupart des cas", et je m'attendais a ce genre de reponse ;) il est raisonnable de penser qu'a l'heure actuelle, la plupart des gens ont une resolution (ecran, en pixels) adaptee a leur taille ecran, et obtiennent donc une resolution de 72 ou 96 dpi (si on considere des moniteurs CRT, ca donne qq chose comme 800*600 sur un 14", 1024*768 sur un 15", 1152*864 sur un 17, 1280*960 sur un 19 etc etc)
maintenant c'est vrai, si on a un tres bon ecran (et de bons yeux si ces foutus webmasters ont defini leur images en pixels ;), on peut monter bien plus haut en resolution ecran (1600*1200 sur un 19 par exemple), et donc obtenir qq chose comme 120 ou 150dpi en sortie.
dans ce cas, l'image definie en pixels est effectivement "plus petite que prevu"
C'est pourquoi de toute façon, il vaut mieux utiliser comme unité de longueur dans les feuilles de styles CSS l'"em" et non le "px".
oui, c'est ce vers quoi tend le web, mais il faurait deja que tous les sites soient flexibles ;) et puis, dans le cas d'un ecran a 150dpi, on est obligé de fournir 2x plus de matiere si on veut une image non pixelisee (matiere qui sera gachee et consommatrice de bande passante dans la plupart des cas, c'est a dire les ecrans dont la resolution ne depasse pas 72 ou 96dpi, a pixels carrés)
Si tu as une image de 4800x4800 pixels (qui selon toi est carrée), la
résolution horizontale étant de 2400 pixels par pouce et la résolution
verticale 4800 pixels par pouce (ces résolutions différentes sur les
deux axes se retrouvent sur certains scanners), tu auras bel et bien une
image qui devrait être affichée avec des dimensions de 2x1 pouces (c'est
un rectangle).
mais quel logiciel gere une resolution differente sur les 2 axes ?
Même dans un site, les tailles de polices de caractères ou d'images
(c'est vrai que pour les images, la technologie est encore limitée, mais
pourquoi pas utiliser du SVG pour les dessins vectoriels par exemple) ne
devraient pas être spécifiés en pixels.
En effet, une marge de 30 pixels pourra en réalité être représentée par
une marge de 1 cm sur certains moniteurs mais 0.00001 cm sur d'autres
(c'est pas moi qui ai payé pour ce moniteur aussi, c'est vrai ;)
j'ai bien dit "dans la plupart des cas", et je m'attendais a ce genre de
reponse ;)
il est raisonnable de penser qu'a l'heure actuelle, la plupart des gens
ont une resolution (ecran, en pixels) adaptee a leur taille ecran, et
obtiennent donc une resolution de 72 ou 96 dpi (si on considere des
moniteurs CRT, ca donne qq chose comme 800*600 sur un 14", 1024*768 sur
un 15", 1152*864 sur un 17, 1280*960 sur un 19 etc etc)
maintenant c'est vrai, si on a un tres bon ecran (et de bons yeux si ces
foutus webmasters ont defini leur images en pixels ;), on peut monter
bien plus haut en resolution ecran (1600*1200 sur un 19 par exemple), et
donc obtenir qq chose comme 120 ou 150dpi en sortie.
dans ce cas, l'image definie en pixels est effectivement "plus petite
que prevu"
C'est pourquoi de toute façon, il vaut mieux utiliser comme unité de
longueur dans les feuilles de styles CSS l'"em" et non le "px".
oui, c'est ce vers quoi tend le web, mais il faurait deja que tous les
sites soient flexibles ;)
et puis, dans le cas d'un ecran a 150dpi, on est obligé de fournir 2x
plus de matiere si on veut une image non pixelisee (matiere qui sera
gachee et consommatrice de bande passante dans la plupart des cas, c'est
a dire les ecrans dont la resolution ne depasse pas 72 ou 96dpi, a
pixels carrés)
Si tu as une image de 4800x4800 pixels (qui selon toi est carrée), la résolution horizontale étant de 2400 pixels par pouce et la résolution verticale 4800 pixels par pouce (ces résolutions différentes sur les deux axes se retrouvent sur certains scanners), tu auras bel et bien une image qui devrait être affichée avec des dimensions de 2x1 pouces (c'est un rectangle).
mais quel logiciel gere une resolution differente sur les 2 axes ?
Même dans un site, les tailles de polices de caractères ou d'images (c'est vrai que pour les images, la technologie est encore limitée, mais pourquoi pas utiliser du SVG pour les dessins vectoriels par exemple) ne devraient pas être spécifiés en pixels. En effet, une marge de 30 pixels pourra en réalité être représentée par une marge de 1 cm sur certains moniteurs mais 0.00001 cm sur d'autres (c'est pas moi qui ai payé pour ce moniteur aussi, c'est vrai ;)
j'ai bien dit "dans la plupart des cas", et je m'attendais a ce genre de reponse ;) il est raisonnable de penser qu'a l'heure actuelle, la plupart des gens ont une resolution (ecran, en pixels) adaptee a leur taille ecran, et obtiennent donc une resolution de 72 ou 96 dpi (si on considere des moniteurs CRT, ca donne qq chose comme 800*600 sur un 14", 1024*768 sur un 15", 1152*864 sur un 17, 1280*960 sur un 19 etc etc)
maintenant c'est vrai, si on a un tres bon ecran (et de bons yeux si ces foutus webmasters ont defini leur images en pixels ;), on peut monter bien plus haut en resolution ecran (1600*1200 sur un 19 par exemple), et donc obtenir qq chose comme 120 ou 150dpi en sortie.
dans ce cas, l'image definie en pixels est effectivement "plus petite que prevu"
C'est pourquoi de toute façon, il vaut mieux utiliser comme unité de longueur dans les feuilles de styles CSS l'"em" et non le "px".
oui, c'est ce vers quoi tend le web, mais il faurait deja que tous les sites soient flexibles ;) et puis, dans le cas d'un ecran a 150dpi, on est obligé de fournir 2x plus de matiere si on veut une image non pixelisee (matiere qui sera gachee et consommatrice de bande passante dans la plupart des cas, c'est a dire les ecrans dont la resolution ne depasse pas 72 ou 96dpi, a pixels carrés)
Quelqu'un aurai une solution pour moi ? Peu être une librairie php ?
Une image n'a pas de dpi! Les dpi n'ont un sens que lors de l'impression. Tant que tu n'imprimes pas la photo, sa taille s'exprime en pixels.
Si, si... Si, par exemple tu veux faire une photocopie. Tu scannes à une résolution quelconque (exprimée en dpi...). Tu obtiens une image avec le dpi de scan. Pour imprimer l'image que tu as stockée, pour obtenir la même (en taille...) ton logiciel d'impression lira les dpi dans le fichier et le restituera dans la bonne taille.
D'ailleurs, c'est une grosse lacune dans les browsers actuels : aucun d'entre eux ne prend en compte les dpi des images des pages Web pour l'impression.
-- Serge http://leserged.online.fr/ Tout sur Windows : http://www.bellamyjc.org/ et http://www.ntfaqfr.com/
Gg a utilisé son clavier pour écrire :
Quelqu'un aurai une solution pour moi ?
Peu être une librairie php ?
Une image n'a pas de dpi! Les dpi n'ont un sens que lors de l'impression.
Tant que tu n'imprimes pas la photo, sa taille s'exprime en pixels.
Si, si...
Si, par exemple tu veux faire une photocopie. Tu scannes à une
résolution quelconque (exprimée en dpi...). Tu obtiens une image avec
le dpi de scan. Pour imprimer l'image que tu as stockée, pour obtenir
la même (en taille...) ton logiciel d'impression lira les dpi dans le
fichier et le restituera dans la bonne taille.
D'ailleurs, c'est une grosse lacune dans les browsers actuels : aucun
d'entre eux ne prend en compte les dpi des images des pages Web pour
l'impression.
--
Serge http://leserged.online.fr/
Tout sur Windows : http://www.bellamyjc.org/ et http://www.ntfaqfr.com/
Quelqu'un aurai une solution pour moi ? Peu être une librairie php ?
Une image n'a pas de dpi! Les dpi n'ont un sens que lors de l'impression. Tant que tu n'imprimes pas la photo, sa taille s'exprime en pixels.
Si, si... Si, par exemple tu veux faire une photocopie. Tu scannes à une résolution quelconque (exprimée en dpi...). Tu obtiens une image avec le dpi de scan. Pour imprimer l'image que tu as stockée, pour obtenir la même (en taille...) ton logiciel d'impression lira les dpi dans le fichier et le restituera dans la bonne taille.
D'ailleurs, c'est une grosse lacune dans les browsers actuels : aucun d'entre eux ne prend en compte les dpi des images des pages Web pour l'impression.
-- Serge http://leserged.online.fr/ Tout sur Windows : http://www.bellamyjc.org/ et http://www.ntfaqfr.com/
Davel_x
Le 03/05/2004 19:39 :
on 3/05/2004 13:46, denisb wrote :
... euh...nan !
et si... suffit de tester dans photoshop par exemple nouvelle image, 72dpi, enregistrer en jpeg changer en 300, sauver sous un autre nom, ouvrir les 2 on retrouve bien l'info des 72 et 300
Ce qui veut dire que ces deux fichiers ne s'imprimeront pas de la même manière même si leurs résolutions en pixels sont identiques.
Pour l'application de René qui a besoin d'un espace d'archivage pour ses images cette information est peut-être importante. Donc s'il ne faut pas la changer il lui faudra éviter d'enregistrer l'image avec GD 2.0 et essayer de faire une fonction qui lise le nombre de dpi dans les infos du fichier.
quelqu'un connait la description des fichiers jpeg ?
-- **davel** http://www.lerpg.com
Le 03/05/2004 19:39 :
on 3/05/2004 13:46, denisb wrote :
...
euh...nan !
et si...
suffit de tester dans photoshop par exemple
nouvelle image, 72dpi, enregistrer en jpeg
changer en 300, sauver sous un autre nom, ouvrir les 2
on retrouve bien l'info des 72 et 300
Ce qui veut dire que ces deux fichiers ne s'imprimeront pas de la même
manière même si leurs résolutions en pixels sont identiques.
Pour l'application de René qui a besoin d'un espace d'archivage pour ses
images cette information est peut-être importante.
Donc s'il ne faut pas la changer il lui faudra éviter d'enregistrer
l'image avec GD 2.0 et essayer de faire une fonction qui lise le nombre
de dpi dans les infos du fichier.
quelqu'un connait la description des fichiers jpeg ?
et si... suffit de tester dans photoshop par exemple nouvelle image, 72dpi, enregistrer en jpeg changer en 300, sauver sous un autre nom, ouvrir les 2 on retrouve bien l'info des 72 et 300
Ce qui veut dire que ces deux fichiers ne s'imprimeront pas de la même manière même si leurs résolutions en pixels sont identiques.
Pour l'application de René qui a besoin d'un espace d'archivage pour ses images cette information est peut-être importante. Donc s'il ne faut pas la changer il lui faudra éviter d'enregistrer l'image avec GD 2.0 et essayer de faire une fonction qui lise le nombre de dpi dans les infos du fichier.
quelqu'un connait la description des fichiers jpeg ?
-- **davel** http://www.lerpg.com
newdb
Davel_x wrote:
> Sergio qui dit : > suffit de tester dans photoshop par exemple > nouvelle image, 72dpi, enregistrer en jpeg > changer en 300, sauver sous un autre nom, ouvrir les 2 > on retrouve bien l'info des 72 et 300
ah. ben oui. ok ok ok ! bon ben j'ai dit une bêtise là alors ...
Ce qui veut dire que ces deux fichiers ne s'imprimeront pas de la même manière même si leurs résolutions en pixels sont identiques.
ils ne s'imprimeront pas à la même taille s'ils sont imprimés 'bruts' (lachés tels quels dans l'imprimante) ce qui n'arrive jamais. enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste, monteur... qui redimensionne le fichier récupéré en fonction de son utilisation finale !
Pour l'application de René qui a besoin d'un espace d'archivage pour ses images cette information est peut-être importante. Donc s'il ne faut pas la changer il lui faudra éviter d'enregistrer l'image avec GD 2.0 et essayer de faire une fonction qui lise le nombre de dpi dans les infos du fichier.
bé... oukilé rené ? ouh ouh ??? pour la base d'images dont je m'occupe, les photographes balancent leurs images haute déf (scans ou prises de vue numériques), mon script (php) en récupère les dimensions en pixels,et gd me sert à créer les vignettes et pré-visues. gd crée une image (par défaut ? toujours ?) en 72dpi en incluant (par défaut ? toujours ?) le commentaire 'CREATOR: gd-jpeg vX.X (using IJG JPEG vXX), quality = XX'. et je ne me préocupe pas des dpi : je calcule juste la taille de l'image telle qu'elle serait si imprimée en 300dpi (avec la formule de mon post précédent donc). quand au volume occupé par les fichiers images, php t'indique trés clairement le 'poids' de la bête...
quelqu'un connait la description des fichiers jpeg ?
2 liens (en français compréhensible !) sur ces fameux en-tête : +++ sur le jpeg/jfif <http://www.ac-reunion.fr/pedagogie/colBretagne/bouquin/fichimag.PDF> particulèrement les pages 12 à 15 du pdf (63 à 66 du document) +++ sur l'exif <http://michel.bisiere.free.fr/Exif_fr.php>
pour corser le tout, on peut aussi (avec php) jouer avec les infos iptc (mots clef, copyright, auteur, ...) quand il y en a, pour les récupérer et les insérer dans une base de données.
-- @@@@@ E -00 simple comme clic clac ! ' `) / |_ =="
Davel_x <davel@noospam.fr> wrote:
> Sergio qui dit :
> suffit de tester dans photoshop par exemple
> nouvelle image, 72dpi, enregistrer en jpeg
> changer en 300, sauver sous un autre nom, ouvrir les 2
> on retrouve bien l'info des 72 et 300
ah. ben oui. ok ok ok !
bon ben j'ai dit une bêtise là alors ...
Ce qui veut dire que ces deux fichiers ne s'imprimeront pas de la même
manière même si leurs résolutions en pixels sont identiques.
ils ne s'imprimeront pas à la même taille s'ils sont imprimés 'bruts'
(lachés tels quels dans l'imprimante) ce qui n'arrive jamais.
enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste,
monteur... qui redimensionne le fichier récupéré en fonction de son
utilisation finale !
Pour l'application de René qui a besoin d'un espace d'archivage pour ses
images cette information est peut-être importante.
Donc s'il ne faut pas la changer il lui faudra éviter d'enregistrer
l'image avec GD 2.0 et essayer de faire une fonction qui lise le nombre
de dpi dans les infos du fichier.
bé... oukilé rené ? ouh ouh ???
pour la base d'images dont je m'occupe, les photographes balancent leurs
images haute déf (scans ou prises de vue numériques), mon script (php)
en récupère les dimensions en pixels,et gd me sert à créer les vignettes
et pré-visues. gd crée une image (par défaut ? toujours ?) en 72dpi en
incluant (par défaut ? toujours ?) le commentaire 'CREATOR: gd-jpeg vX.X
(using IJG JPEG vXX), quality = XX'.
et je ne me préocupe pas des dpi : je calcule juste la taille de l'image
telle qu'elle serait si imprimée en 300dpi (avec la formule de mon post
précédent donc).
quand au volume occupé par les fichiers images, php t'indique trés
clairement le 'poids' de la bête...
quelqu'un connait la description des fichiers jpeg ?
2 liens (en français compréhensible !) sur ces fameux en-tête :
+++ sur le jpeg/jfif
<http://www.ac-reunion.fr/pedagogie/colBretagne/bouquin/fichimag.PDF>
particulèrement les pages 12 à 15 du pdf (63 à 66 du document)
+++ sur l'exif
<http://michel.bisiere.free.fr/Exif_fr.php>
pour corser le tout, on peut aussi (avec php) jouer avec les infos iptc
(mots clef, copyright, auteur, ...) quand il y en a, pour les récupérer
et les insérer dans une base de données.
--
@@@@@
E -00 simple comme clic clac !
' `) /
|_ =="
> Sergio qui dit : > suffit de tester dans photoshop par exemple > nouvelle image, 72dpi, enregistrer en jpeg > changer en 300, sauver sous un autre nom, ouvrir les 2 > on retrouve bien l'info des 72 et 300
ah. ben oui. ok ok ok ! bon ben j'ai dit une bêtise là alors ...
Ce qui veut dire que ces deux fichiers ne s'imprimeront pas de la même manière même si leurs résolutions en pixels sont identiques.
ils ne s'imprimeront pas à la même taille s'ils sont imprimés 'bruts' (lachés tels quels dans l'imprimante) ce qui n'arrive jamais. enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste, monteur... qui redimensionne le fichier récupéré en fonction de son utilisation finale !
Pour l'application de René qui a besoin d'un espace d'archivage pour ses images cette information est peut-être importante. Donc s'il ne faut pas la changer il lui faudra éviter d'enregistrer l'image avec GD 2.0 et essayer de faire une fonction qui lise le nombre de dpi dans les infos du fichier.
bé... oukilé rené ? ouh ouh ??? pour la base d'images dont je m'occupe, les photographes balancent leurs images haute déf (scans ou prises de vue numériques), mon script (php) en récupère les dimensions en pixels,et gd me sert à créer les vignettes et pré-visues. gd crée une image (par défaut ? toujours ?) en 72dpi en incluant (par défaut ? toujours ?) le commentaire 'CREATOR: gd-jpeg vX.X (using IJG JPEG vXX), quality = XX'. et je ne me préocupe pas des dpi : je calcule juste la taille de l'image telle qu'elle serait si imprimée en 300dpi (avec la formule de mon post précédent donc). quand au volume occupé par les fichiers images, php t'indique trés clairement le 'poids' de la bête...
quelqu'un connait la description des fichiers jpeg ?
2 liens (en français compréhensible !) sur ces fameux en-tête : +++ sur le jpeg/jfif <http://www.ac-reunion.fr/pedagogie/colBretagne/bouquin/fichimag.PDF> particulèrement les pages 12 à 15 du pdf (63 à 66 du document) +++ sur l'exif <http://michel.bisiere.free.fr/Exif_fr.php>
pour corser le tout, on peut aussi (avec php) jouer avec les infos iptc (mots clef, copyright, auteur, ...) quand il y en a, pour les récupérer et les insérer dans une base de données.
-- @@@@@ E -00 simple comme clic clac ! ' `) / |_ =="
Thibaut Allender
on 5/05/2004 0:36, denisb wrote :
Sergio qui dit : suffit de tester dans photoshop par exemple
non c'est moi qui ai dit ca :)
ils ne s'imprimeront pas à la même taille s'ils sont imprimés 'bruts' (lachés tels quels dans l'imprimante) ce qui n'arrive jamais. enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste, monteur... qui redimensionne le fichier récupéré en fonction de son utilisation finale !
l'utilisateur lambda qui fait ses photos numeriques n'est ni graphiste, ni maquettiste, ni monteur par contre, il peut posseder une imprimante et vouloir imprimer ses cliches ;)
Sergio qui dit :
suffit de tester dans photoshop par exemple
non c'est moi qui ai dit ca :)
ils ne s'imprimeront pas à la même taille s'ils sont imprimés 'bruts'
(lachés tels quels dans l'imprimante) ce qui n'arrive jamais.
enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste,
monteur... qui redimensionne le fichier récupéré en fonction de son
utilisation finale !
l'utilisateur lambda qui fait ses photos numeriques n'est ni graphiste,
ni maquettiste, ni monteur
par contre, il peut posseder une imprimante et vouloir imprimer ses
cliches ;)
Sergio qui dit : suffit de tester dans photoshop par exemple
non c'est moi qui ai dit ca :)
ils ne s'imprimeront pas à la même taille s'ils sont imprimés 'bruts' (lachés tels quels dans l'imprimante) ce qui n'arrive jamais. enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste, monteur... qui redimensionne le fichier récupéré en fonction de son utilisation finale !
l'utilisateur lambda qui fait ses photos numeriques n'est ni graphiste, ni maquettiste, ni monteur par contre, il peut posseder une imprimante et vouloir imprimer ses cliches ;)
on 5/05/2004 0:36, denisb wrote : >>>Sergio qui dit : >>>suffit de tester dans photoshop par exemple non c'est moi qui ai dit ca :)
grrrmmphhh... ta: 1 - db: 0
> enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste, > monteur... qui redimensionne le fichier récupéré en fonction de son > utilisation finale ! l'utilisateur lambda qui fait ses photos numeriques n'est ni graphiste, ni maquettiste, ni monteur par contre, il peut posseder une imprimante et vouloir imprimer ses cliches ;)
on 5/05/2004 0:36, denisb wrote :
>>>Sergio qui dit :
>>>suffit de tester dans photoshop par exemple
non c'est moi qui ai dit ca :)
grrrmmphhh...
ta: 1 - db: 0
> enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste,
> monteur... qui redimensionne le fichier récupéré en fonction de son
> utilisation finale !
l'utilisateur lambda qui fait ses photos numeriques n'est ni graphiste,
ni maquettiste, ni monteur
par contre, il peut posseder une imprimante et vouloir imprimer ses
cliches ;)
on 5/05/2004 0:36, denisb wrote : >>>Sergio qui dit : >>>suffit de tester dans photoshop par exemple non c'est moi qui ai dit ca :)
grrrmmphhh... ta: 1 - db: 0
> enfin, je pense qu'il y a 'toujours' un graphiste, maquettiste, > monteur... qui redimensionne le fichier récupéré en fonction de son > utilisation finale ! l'utilisateur lambda qui fait ses photos numeriques n'est ni graphiste, ni maquettiste, ni monteur par contre, il peut posseder une imprimante et vouloir imprimer ses cliches ;)
