Bonjour à tous
J'ai voulu envoyer des photos que j'ai sur un cd kodak qui vienne de
diapositive, elles sont en format PCD et font 4,9 Mo, je peux les visionner
à l'écran, mais pour faire des agrandissements envoyer par internet, je
suis obligé de les transformer .
J'ai essayé tout un tas de format, en JPG, cela me les réduit à 354 KO, en
TIF à 1,12 Mo, en BMP à 1,12 Mo et par image photo shop à 1,05 Mo.
N'auriez vous pas une combine ou un logiciel qui me permette de les ouvrir ,
et de pouvoir garder la taille initiale de ces photos.
Merci par avance.
Picasa travaille d'une façon vraiment très subtile (pour moi...). Quand tu appliques des modifications à une image, elles semblent définitives, mais en fait non. D'une part si tu regardes l'image dans l'explorateur et non dans Picasa, c'est toujours l'image d'origine qui est là ! D'autre part, si tu rouvres cette image modifiée dans Picasa, toutes les modifications faites sont réversibles ! En fait, Picasa met de côté la version modifiée de ton image, avec un fichier des modifications et c'est seulement cette version modifiée qu'il affiche. Il m'a fallu un moment pour comprendre ça.
En fait il y a deux choses:
- Picasa enregistre par défaut les modifs en dehors de la photo (ce qui lilite un peu ses posibilités, d'ailleurs), dans un fichier caché dur répertoire.
- On peut demander de finaliser la photo (envoi à un tiers), à ce moment Picasa copie la photo d'origine dans un sous-répertoire ("originals", de mémoire)
-- Bertrand
On 05/02/2011 11:18 PM, Ghost-Rider wrote:
Picasa travaille d'une façon vraiment très subtile (pour moi...).
Quand tu appliques des modifications à une image, elles semblent
définitives, mais en fait non.
D'une part si tu regardes l'image dans l'explorateur et non dans Picasa,
c'est toujours l'image d'origine qui est là !
D'autre part, si tu rouvres cette image modifiée dans Picasa, toutes les
modifications faites sont réversibles !
En fait, Picasa met de côté la version modifiée de ton image, avec un
fichier des modifications et c'est seulement cette version modifiée
qu'il affiche.
Il m'a fallu un moment pour comprendre ça.
En fait il y a deux choses:
- Picasa enregistre par défaut les modifs en dehors de la photo (ce qui
lilite un peu ses posibilités, d'ailleurs), dans un fichier caché dur
répertoire.
- On peut demander de finaliser la photo (envoi à un tiers), à ce moment
Picasa copie la photo d'origine dans un sous-répertoire ("originals", de
mémoire)
Picasa travaille d'une façon vraiment très subtile (pour moi...). Quand tu appliques des modifications à une image, elles semblent définitives, mais en fait non. D'une part si tu regardes l'image dans l'explorateur et non dans Picasa, c'est toujours l'image d'origine qui est là ! D'autre part, si tu rouvres cette image modifiée dans Picasa, toutes les modifications faites sont réversibles ! En fait, Picasa met de côté la version modifiée de ton image, avec un fichier des modifications et c'est seulement cette version modifiée qu'il affiche. Il m'a fallu un moment pour comprendre ça.
En fait il y a deux choses:
- Picasa enregistre par défaut les modifs en dehors de la photo (ce qui lilite un peu ses posibilités, d'ailleurs), dans un fichier caché dur répertoire.
- On peut demander de finaliser la photo (envoi à un tiers), à ce moment Picasa copie la photo d'origine dans un sous-répertoire ("originals", de mémoire)
-- Bertrand
Stephane Legras-Decussy
Le 02/05/2011 20:18, Papy bernard a écrit :
A une image de 10Mpixels en 16 millions de couleurs correspond, en RAM, à 30 Mo. Que cette image provienne d'un *.TIF ou d'un *JPG compressé à mort.
sauf que ce sera en pratique 40 Mo de RAM, car on prendra 32 bit par pixel.
Pas question d'adresser des blocs de mémoire avec une granularité de 3 octets (non puissance de 2).
c'est pas grave puisque ça permet d'inclure la couche alpha. l'octet "gaché" ne l'est pas.
Possible que sur OS 64bit, un soft un peu bourrin alloue même 64 bit par pixel... 80Mo la 10Mpix.
Le 02/05/2011 20:18, Papy bernard a écrit :
A une image de 10Mpixels en 16 millions de couleurs correspond, en RAM, à 30
Mo. Que cette image provienne d'un *.TIF ou d'un *JPG compressé à mort.
sauf que ce sera en pratique 40 Mo de RAM, car on prendra
32 bit par pixel.
Pas question d'adresser des blocs de mémoire
avec une granularité de 3 octets (non puissance de 2).
c'est pas grave puisque ça permet d'inclure la couche alpha.
l'octet "gaché" ne l'est pas.
Possible que sur OS 64bit, un soft un peu bourrin alloue même
64 bit par pixel... 80Mo la 10Mpix.
A une image de 10Mpixels en 16 millions de couleurs correspond, en RAM, à 30 Mo. Que cette image provienne d'un *.TIF ou d'un *JPG compressé à mort.
sauf que ce sera en pratique 40 Mo de RAM, car on prendra 32 bit par pixel.
Pas question d'adresser des blocs de mémoire avec une granularité de 3 octets (non puissance de 2).
c'est pas grave puisque ça permet d'inclure la couche alpha. l'octet "gaché" ne l'est pas.
Possible que sur OS 64bit, un soft un peu bourrin alloue même 64 bit par pixel... 80Mo la 10Mpix.
Stephane Legras-Decussy
Le 02/05/2011 21:42, René a écrit :
Tu prends une photo de 2500 pixels de haut et tu la regardes sur ton écran à moins de 1000 lignes. L'affichage te montre 2,5 pixels réduits en une moyenne de 1 pixel (sans tenir compte de la largeur).
mwoui...
De la même photo tu fais tirer un 10x15; les 2500 pixels seront donc recalculé à 25 pixels par mm. Le JPG font des sortes de moyennes par blocs de 8x8 pixels.
là je comprends pas de quoi tu parles.
le jpg est juste pour stocker sur fichier, dans la mémoire vive de l'ordi je jpeg n'existe plus, c'est toujours un bitmap.
ensuite si tu imprimes tes 25 pixel par mm, c'est le rôle du driver d'impression de projeter ces 25 pixels par rapport à la résolution physique d'impression.
Le 02/05/2011 21:42, René a écrit :
Tu prends une photo de 2500 pixels de haut et tu la regardes sur ton
écran à moins de 1000 lignes. L'affichage te montre 2,5 pixels réduits
en une moyenne de 1 pixel (sans tenir compte de la largeur).
mwoui...
De la même
photo tu fais tirer un 10x15; les 2500 pixels seront donc recalculé à 25
pixels par mm. Le JPG font des sortes de moyennes par blocs de 8x8
pixels.
là je comprends pas de quoi tu parles.
le jpg est juste pour stocker sur fichier, dans
la mémoire vive de l'ordi je jpeg n'existe plus, c'est
toujours un bitmap.
ensuite si tu imprimes tes 25 pixel par mm, c'est le rôle du driver
d'impression de projeter ces 25 pixels par rapport à la résolution
physique d'impression.
Tu prends une photo de 2500 pixels de haut et tu la regardes sur ton écran à moins de 1000 lignes. L'affichage te montre 2,5 pixels réduits en une moyenne de 1 pixel (sans tenir compte de la largeur).
mwoui...
De la même photo tu fais tirer un 10x15; les 2500 pixels seront donc recalculé à 25 pixels par mm. Le JPG font des sortes de moyennes par blocs de 8x8 pixels.
là je comprends pas de quoi tu parles.
le jpg est juste pour stocker sur fichier, dans la mémoire vive de l'ordi je jpeg n'existe plus, c'est toujours un bitmap.
ensuite si tu imprimes tes 25 pixel par mm, c'est le rôle du driver d'impression de projeter ces 25 pixels par rapport à la résolution physique d'impression.
Stephane Legras-Decussy
Le 02/05/2011 23:04, Ghost-Rider a écrit :
C'est ce principe de moyenner des pixels que je n'ai jamais compris alors qu'il existe des algorithme non destructifs, comme le ZIP.
le jpeg comprime avec du ZIP !
mais pour comprimer en ZIP il faut beaucoup de chiffres identiques, pas de bol une image c'est que des chiffres différents.
donc l'algo jpeg transforme l'image de manière à faire apparaitre beaucoup de chiffres identiques.
ensuite ça roule pour le ZIP.
c'est tout con.
Le 02/05/2011 23:04, Ghost-Rider a écrit :
C'est ce principe de moyenner des pixels que je n'ai jamais compris
alors qu'il existe des algorithme non destructifs, comme le ZIP.
le jpeg comprime avec du ZIP !
mais pour comprimer en ZIP il faut beaucoup
de chiffres identiques, pas de bol une image c'est que
des chiffres différents.
donc l'algo jpeg transforme l'image de manière à faire
apparaitre beaucoup de chiffres identiques.
C'est ce principe de moyenner des pixels que je n'ai jamais compris alors qu'il existe des algorithme non destructifs, comme le ZIP.
le jpeg comprime avec du ZIP !
mais pour comprimer en ZIP il faut beaucoup de chiffres identiques, pas de bol une image c'est que des chiffres différents.
donc l'algo jpeg transforme l'image de manière à faire apparaitre beaucoup de chiffres identiques.
ensuite ça roule pour le ZIP.
c'est tout con.
Stephane Legras-Decussy
Le 02/05/2011 17:35, YouDontNeedToKnowButItsNoëlle a écrit :
Le 01/05/11 17:51, Stephane Legras-Decussy a écrit :
c'est contraignant mais c'est le seul chiffrement d'une sécurité absolue.
Il n'y a pas de sécurité absolue qui repose sur une transmission qui peut être captée.
bah si, je viens de raconter pourquoi.
avec la clé jetable aussi longue que le message, personne ne peut déchiffrer sans la clé.
http://fr.wikipedia.org/wiki/Masque_jetable
C'est à ce problème que répondent les systèmes à clé publique et clé privée.
ça peut se casser sans la clé en faisant mouliner un ordi, ou avec des clés faibles, alors que le précédent non.
de même c'est vulnérable par une attaque man-in-the-middle... etc
les systèmes asymétriques ne sont pas la panacée, pour preuve le gouvernement US vient d'adopter en 2002 l'AES, symétrique... alors que PGP existe depuis très longtemps.
Le 02/05/2011 17:35, YouDontNeedToKnowButItsNoëlle a écrit :
Le 01/05/11 17:51, Stephane Legras-Decussy a écrit :
c'est contraignant mais c'est le seul chiffrement d'une sécurité absolue.
Il n'y a pas de sécurité absolue qui repose sur une transmission qui
peut être captée.
bah si, je viens de raconter pourquoi.
avec la clé jetable aussi longue que le message, personne ne
peut déchiffrer sans la clé.
http://fr.wikipedia.org/wiki/Masque_jetable
C'est à ce problème que répondent les systèmes à clé publique et clé
privée.
ça peut se casser sans la clé en faisant mouliner un ordi, ou avec des
clés faibles, alors que le précédent non.
de même c'est vulnérable par une attaque man-in-the-middle... etc
les systèmes asymétriques ne sont pas la panacée,
pour preuve le gouvernement US vient d'adopter en 2002 l'AES,
symétrique... alors que PGP existe depuis très longtemps.
Le 02/05/2011 17:35, YouDontNeedToKnowButItsNoëlle a écrit :
Le 01/05/11 17:51, Stephane Legras-Decussy a écrit :
c'est contraignant mais c'est le seul chiffrement d'une sécurité absolue.
Il n'y a pas de sécurité absolue qui repose sur une transmission qui peut être captée.
bah si, je viens de raconter pourquoi.
avec la clé jetable aussi longue que le message, personne ne peut déchiffrer sans la clé.
http://fr.wikipedia.org/wiki/Masque_jetable
C'est à ce problème que répondent les systèmes à clé publique et clé privée.
ça peut se casser sans la clé en faisant mouliner un ordi, ou avec des clés faibles, alors que le précédent non.
de même c'est vulnérable par une attaque man-in-the-middle... etc
les systèmes asymétriques ne sont pas la panacée, pour preuve le gouvernement US vient d'adopter en 2002 l'AES, symétrique... alors que PGP existe depuis très longtemps.
Stephane Legras-Decussy
Le 02/05/2011 21:18, René a écrit :
Une bonne manière pour ne rien voir est de regarder sa photo de 14 Mo entière sur un écran en 1024 pixels. L'affichage se charge de tout rendre "parfait sur mon écran" puis d'envoyer un "jpg pour le web" en espérant obtenir un poster.
si on prend une image avec du grain c'est pourtant exactement le contraire qui se passe.
l'affichage du jpeg 4000 x 3000 est très moche sur l'écran 1024 lignes, alors que le jpeg imprimé en poster A3 est superbe.
ya pas de mal à se tromper, j'ai archivé en tiff pendant quelques années avant de me rendre à l'évidence que le jpeg le vaut largement même si ça fait hélas moins snob.
Le 02/05/2011 21:18, René a écrit :
Une bonne manière pour ne rien voir est de regarder sa photo de 14 Mo
entière sur un écran en 1024 pixels. L'affichage se charge de tout
rendre "parfait sur mon écran" puis d'envoyer un "jpg pour le web" en
espérant obtenir un poster.
si on prend une image avec du grain c'est pourtant exactement
le contraire qui se passe.
l'affichage du jpeg 4000 x 3000 est très moche sur l'écran 1024 lignes,
alors que le jpeg imprimé en poster A3 est superbe.
ya pas de mal à se tromper, j'ai archivé en tiff pendant quelques
années avant de me rendre à l'évidence que le jpeg le vaut largement
même si ça fait hélas moins snob.
Une bonne manière pour ne rien voir est de regarder sa photo de 14 Mo entière sur un écran en 1024 pixels. L'affichage se charge de tout rendre "parfait sur mon écran" puis d'envoyer un "jpg pour le web" en espérant obtenir un poster.
si on prend une image avec du grain c'est pourtant exactement le contraire qui se passe.
l'affichage du jpeg 4000 x 3000 est très moche sur l'écran 1024 lignes, alors que le jpeg imprimé en poster A3 est superbe.
ya pas de mal à se tromper, j'ai archivé en tiff pendant quelques années avant de me rendre à l'évidence que le jpeg le vaut largement même si ça fait hélas moins snob.
René
"Stephane Legras-Decussy" a écrit dans le message de groupe de discussion : 4dbf306b$0$27731$
là je comprends pas de quoi tu parles.
Je me suis exprimé trop simplement. Je voulais montrer que les déformations que causes un enregistrement en JPG peuvent être réduites à néant (invisible et fusionnés dans les calculs) lors de l'impression puisque linéairement 25 pixels de l'image seront réduits à un espace de un millimètre. Et que le logiciel d'impression devra calculer le nombre et la couleur des gouttes d'encre nécessaire à la tâche.
"Stephane Legras-Decussy" a écrit dans le message de groupe de discussion
: 4dbf306b$0$27731$426a74cc@news.free.fr...
là je comprends pas de quoi tu parles.
Je me suis exprimé trop simplement. Je voulais montrer que les déformations
que causes un enregistrement en JPG peuvent être réduites à néant (invisible
et fusionnés dans les calculs) lors de l'impression puisque linéairement 25
pixels de l'image seront réduits à un espace de un millimètre. Et que le
logiciel d'impression devra calculer le nombre et la couleur des gouttes
d'encre nécessaire à la tâche.
"Stephane Legras-Decussy" a écrit dans le message de groupe de discussion : 4dbf306b$0$27731$
là je comprends pas de quoi tu parles.
Je me suis exprimé trop simplement. Je voulais montrer que les déformations que causes un enregistrement en JPG peuvent être réduites à néant (invisible et fusionnés dans les calculs) lors de l'impression puisque linéairement 25 pixels de l'image seront réduits à un espace de un millimètre. Et que le logiciel d'impression devra calculer le nombre et la couleur des gouttes d'encre nécessaire à la tâche.
lemorse17
Bonjour Je ne pensais pas que ma petite question allait faire un aussi grand débat, mais en tout les cas je vous remercie beaucoup de toutes ces explications. Cordialement
"Stephane Legras-Decussy" a écrit dans le message de news: 4dbf0dfd$0$25229$
Le 02/05/2011 19:28, René a écrit :
Bonjour Charles
Je n'ai nullement envie de défendre le TIF ou quoi que ce soit. Mais le JPG sans perte n'existe pas.
euh... ça s'appelle le lossless jpeg.
http://en.wikipedia.org/wiki/Lossless_JPEG
(mais je te taquine, c'est un algo différent)
Bonjour
Je ne pensais pas que ma petite question allait faire un aussi grand débat,
mais en tout les cas je vous remercie beaucoup de toutes ces explications.
Cordialement
"Stephane Legras-Decussy" <killyourself@yesnocancel.com> a écrit dans le
message de news: 4dbf0dfd$0$25229$426a74cc@news.free.fr...
Le 02/05/2011 19:28, René a écrit :
Bonjour Charles
Je n'ai nullement envie de défendre le TIF ou quoi que ce soit.
Mais le JPG sans perte n'existe pas.
Bonjour Je ne pensais pas que ma petite question allait faire un aussi grand débat, mais en tout les cas je vous remercie beaucoup de toutes ces explications. Cordialement
"Stephane Legras-Decussy" a écrit dans le message de news: 4dbf0dfd$0$25229$
Le 02/05/2011 19:28, René a écrit :
Bonjour Charles
Je n'ai nullement envie de défendre le TIF ou quoi que ce soit. Mais le JPG sans perte n'existe pas.
euh... ça s'appelle le lossless jpeg.
http://en.wikipedia.org/wiki/Lossless_JPEG
(mais je te taquine, c'est un algo différent)
Stephane Legras-Decussy
Le 03/05/2011 07:38, René a écrit :
Je me suis exprimé trop simplement. Je voulais montrer que les déformations que causes un enregistrement en JPG peuvent être réduites à néant (invisible et fusionnés dans les calculs) lors de l'impression puisque linéairement 25 pixels de l'image seront réduits à un espace de un millimètre. Et que le logiciel d'impression devra calculer le nombre et la couleur des gouttes d'encre nécessaire à la tâche.
oui mais avec 12 pixels par mm ça se produit aussi... et ce sont les 300 dpi d'impression pro.
Le 03/05/2011 07:38, René a écrit :
Je me suis exprimé trop simplement. Je voulais montrer que les
déformations que causes un enregistrement en JPG peuvent être réduites à
néant (invisible et fusionnés dans les calculs) lors de l'impression
puisque linéairement 25 pixels de l'image seront réduits à un espace de
un millimètre. Et que le logiciel d'impression devra calculer le nombre
et la couleur des gouttes d'encre nécessaire à la tâche.
oui mais avec 12 pixels par mm ça se
produit aussi... et ce sont les 300 dpi d'impression pro.
Je me suis exprimé trop simplement. Je voulais montrer que les déformations que causes un enregistrement en JPG peuvent être réduites à néant (invisible et fusionnés dans les calculs) lors de l'impression puisque linéairement 25 pixels de l'image seront réduits à un espace de un millimètre. Et que le logiciel d'impression devra calculer le nombre et la couleur des gouttes d'encre nécessaire à la tâche.
oui mais avec 12 pixels par mm ça se produit aussi... et ce sont les 300 dpi d'impression pro.
lemorse17
Re bonjour Puisque vous êtes si gentil, je voulais vous poser une autre question, car avec toutes les réponses que j'ai reçue , j'ai essayé de nouvelles choses. C'est à dire que mon fichier en en PCD qui mesure 4,31 Mo , je l'ai ouvert avec Photo filtre, car c'est dommage que l'on ne puisse l'ouvrir avec View NX2, mais bon , les dimensions sont de 768 x 512, si je le convertie directement en JPEG , je me retrouve avec un fichier de 277 KO, par contre si je joue avec toujours dans P.F avec la taille de l'image en la passant en 1768 x 1512 en que je la convertie en JPEG , j'obtiens 1,19 MO et si je passe à 3768 x 2512 j'arrive à 3,18 MO, ma question va vous paraitre peut être bête , mais toujours par rapport à un tirage papier, est que cela va l'améliorer en prenant 3,18 MO ou le tirage sera toujours aussi mauvais quand le laissant en 768 x512 . Encore merci pour vos réponses. Cordialement
"lemorse17" a écrit dans le message de news: ipdmqm$16m6$
Bonjour à tous J'ai voulu envoyer des photos que j'ai sur un cd kodak qui vienne de diapositive, elles sont en format PCD et font 4,9 Mo, je peux les visionner à l'écran, mais pour faire des agrandissements envoyer par internet, je suis obligé de les transformer . J'ai essayé tout un tas de format, en JPG, cela me les réduit à 354 KO, en TIF à 1,12 Mo, en BMP à 1,12 Mo et par image photo shop à 1,05 Mo. N'auriez vous pas une combine ou un logiciel qui me permette de les ouvrir , et de pouvoir garder la taille initiale de ces photos. Merci par avance.
Re bonjour
Puisque vous êtes si gentil, je voulais vous poser une autre question, car
avec toutes les réponses que j'ai reçue , j'ai essayé de nouvelles choses.
C'est à dire que mon fichier en en PCD qui mesure 4,31 Mo , je l'ai ouvert
avec Photo filtre, car c'est dommage que l'on ne puisse l'ouvrir avec
View NX2, mais bon , les dimensions sont de 768 x 512, si je le convertie
directement en JPEG , je me retrouve avec un fichier de 277 KO, par contre
si je joue avec toujours dans P.F avec la taille de l'image en la passant en
1768 x 1512 en que je la convertie en JPEG , j'obtiens 1,19 MO et si je
passe à 3768 x 2512 j'arrive à 3,18 MO, ma question va vous paraitre peut
être bête , mais toujours par rapport à un tirage papier, est que cela va
l'améliorer en prenant 3,18 MO ou le tirage sera toujours aussi mauvais
quand le laissant en 768 x512 .
Encore merci pour vos réponses.
Cordialement
"lemorse17" <lemorse17@sfr.fr> a écrit dans le message de news:
ipdmqm$16m6$1@talisker.lacave.net...
Bonjour à tous
J'ai voulu envoyer des photos que j'ai sur un cd kodak qui vienne de
diapositive, elles sont en format PCD et font 4,9 Mo, je peux les
visionner
à l'écran, mais pour faire des agrandissements envoyer par internet, je
suis obligé de les transformer .
J'ai essayé tout un tas de format, en JPG, cela me les réduit à 354 KO, en
TIF à 1,12 Mo, en BMP à 1,12 Mo et par image photo shop à 1,05 Mo.
N'auriez vous pas une combine ou un logiciel qui me permette de les ouvrir
,
et de pouvoir garder la taille initiale de ces photos.
Merci par avance.
Re bonjour Puisque vous êtes si gentil, je voulais vous poser une autre question, car avec toutes les réponses que j'ai reçue , j'ai essayé de nouvelles choses. C'est à dire que mon fichier en en PCD qui mesure 4,31 Mo , je l'ai ouvert avec Photo filtre, car c'est dommage que l'on ne puisse l'ouvrir avec View NX2, mais bon , les dimensions sont de 768 x 512, si je le convertie directement en JPEG , je me retrouve avec un fichier de 277 KO, par contre si je joue avec toujours dans P.F avec la taille de l'image en la passant en 1768 x 1512 en que je la convertie en JPEG , j'obtiens 1,19 MO et si je passe à 3768 x 2512 j'arrive à 3,18 MO, ma question va vous paraitre peut être bête , mais toujours par rapport à un tirage papier, est que cela va l'améliorer en prenant 3,18 MO ou le tirage sera toujours aussi mauvais quand le laissant en 768 x512 . Encore merci pour vos réponses. Cordialement
"lemorse17" a écrit dans le message de news: ipdmqm$16m6$
Bonjour à tous J'ai voulu envoyer des photos que j'ai sur un cd kodak qui vienne de diapositive, elles sont en format PCD et font 4,9 Mo, je peux les visionner à l'écran, mais pour faire des agrandissements envoyer par internet, je suis obligé de les transformer . J'ai essayé tout un tas de format, en JPG, cela me les réduit à 354 KO, en TIF à 1,12 Mo, en BMP à 1,12 Mo et par image photo shop à 1,05 Mo. N'auriez vous pas une combine ou un logiciel qui me permette de les ouvrir , et de pouvoir garder la taille initiale de ces photos. Merci par avance.
