J'ai un problème avec des images Tiff créées sous Windows XP avec un
scanner Nikon. Lorsque j'ouvre les images sur mon Powerbook sous Tiger
soit avec Gimp, soit avec xv (deux programmes qui utilisent le serveur X),
il y a une perte de qualité des couleurs (perte de saturation). Par contre
si j'ouvre avec le visualiseur standard de Tiger l'image est bonne. J'ai
essayé de changer la configuration de X (millions de couleurs...), mais ça
ne fait rien.
J'ai téléchargé sur le web une image Tiff autre que celle qui a été créée
avec ce scanner et là il n'y a aucun problème. Est-ce que le serveur X a
des problèmes avec certaines images Tiff?
Merci pour vos commentaires,
Christophe
-----
échangez opinions et commentaires dans les forums de discussion.
http://www.usenetgratuit.com/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Saïd
(Ramananjaona Christophe) :
Bonjour,
J'ai un problème avec des images Tiff créées sous Windows XP avec un scanner Nikon. Lorsque j'ouvre les images sur mon Powerbook sous Tiger soit avec Gimp, soit avec xv (deux programmes qui utilisent le serveur X),
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait expliquer le probleme (difference dans l'algorithme pour ramener une image 16bits vers une image 8bits (necessaire a l'affichage)).
Dans xv, appuyer sur i dans la fenetre de l'image.
il y a une perte de qualité des couleurs (perte de saturation). Par contre si j'ouvre avec le visualiseur standard de Tiger l'image est bonne. J'ai essayé de changer la configuration de X (millions de couleurs...), mais ça ne fait rien.
-- Saïd. "Bless this, O Lord, that with it thou mayst blow thine enemies to tiny bits, in thy mercy." In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
J'ai un problème avec des images Tiff créées sous Windows XP avec un
scanner Nikon. Lorsque j'ouvre les images sur mon Powerbook sous Tiger
soit avec Gimp, soit avec xv (deux programmes qui utilisent le serveur X),
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait
expliquer le probleme (difference dans l'algorithme pour ramener une image
16bits vers une image 8bits (necessaire a l'affichage)).
Dans xv, appuyer sur i dans la fenetre de l'image.
il y a une perte de qualité des couleurs (perte de saturation). Par contre
si j'ouvre avec le visualiseur standard de Tiger l'image est bonne. J'ai
essayé de changer la configuration de X (millions de couleurs...), mais ça
ne fait rien.
--
Saïd.
"Bless this, O Lord, that with it thou mayst blow thine enemies to tiny
bits, in thy mercy."
In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
J'ai un problème avec des images Tiff créées sous Windows XP avec un scanner Nikon. Lorsque j'ouvre les images sur mon Powerbook sous Tiger soit avec Gimp, soit avec xv (deux programmes qui utilisent le serveur X),
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait expliquer le probleme (difference dans l'algorithme pour ramener une image 16bits vers une image 8bits (necessaire a l'affichage)).
Dans xv, appuyer sur i dans la fenetre de l'image.
il y a une perte de qualité des couleurs (perte de saturation). Par contre si j'ouvre avec le visualiseur standard de Tiger l'image est bonne. J'ai essayé de changer la configuration de X (millions de couleurs...), mais ça ne fait rien.
-- Saïd. "Bless this, O Lord, that with it thou mayst blow thine enemies to tiny bits, in thy mercy." In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
Eric Levenez
Le 22/09/06 13:52, dans <4513ce7f$0$18128$, « Ramananjaona Christophe » a écrit :
J'ai un problème avec des images Tiff créées sous Windows XP avec un scanner Nikon. Lorsque j'ouvre les images sur mon Powerbook sous Tiger soit avec Gimp, soit avec xv (deux programmes qui utilisent le serveur X), il y a une perte de qualité des couleurs (perte de saturation). Par contre si j'ouvre avec le visualiseur standard de Tiger l'image est bonne. J'ai essayé de changer la configuration de X (millions de couleurs...), mais ça ne fait rien.
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/09/06 13:52, dans <4513ce7f$0$18128$636a55ce@news.free.fr>,
« Ramananjaona Christophe » <cramananjaona...@yahoo.co.uk> a écrit :
J'ai un problème avec des images Tiff créées sous Windows XP avec un
scanner Nikon. Lorsque j'ouvre les images sur mon Powerbook sous Tiger
soit avec Gimp, soit avec xv (deux programmes qui utilisent le serveur X),
il y a une perte de qualité des couleurs (perte de saturation). Par contre
si j'ouvre avec le visualiseur standard de Tiger l'image est bonne. J'ai
essayé de changer la configuration de X (millions de couleurs...), mais ça
ne fait rien.
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs
pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces
champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/09/06 13:52, dans <4513ce7f$0$18128$, « Ramananjaona Christophe » a écrit :
J'ai un problème avec des images Tiff créées sous Windows XP avec un scanner Nikon. Lorsque j'ouvre les images sur mon Powerbook sous Tiger soit avec Gimp, soit avec xv (deux programmes qui utilisent le serveur X), il y a une perte de qualité des couleurs (perte de saturation). Par contre si j'ouvre avec le visualiseur standard de Tiger l'image est bonne. J'ai essayé de changer la configuration de X (millions de couleurs...), mais ça ne fait rien.
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Gilles
Le 22/09/06 13:52, dans <4513ce7f$0$18128$,
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ça explique pourquoi la nouvelle version de Scribus donne des images en espèce de bichromie 'jaune/vert" pâle ?
Gilles Ôter le OT pour m'écrire
Le 22/09/06 13:52, dans <4513ce7f$0$18128$636a55ce@news.free.fr>,
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs
pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces
champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ça explique pourquoi la nouvelle version de Scribus donne des images en
espèce de bichromie 'jaune/vert" pâle ?
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ça explique pourquoi la nouvelle version de Scribus donne des images en espèce de bichromie 'jaune/vert" pâle ?
Gilles Ôter le OT pour m'écrire
Eric Levenez
Le 23/09/06 1:16, dans <45146eb2$0$25943$, « Gilles » a écrit :
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ça explique pourquoi la nouvelle version de Scribus donne des images en
espèce de bichromie 'jaune/vert" pâle ?
Dans le format TIFF il y a aussi énormément de possibilité de variation. Par exemple une couleur (genre rouge) peut être codée sur 8 bits, mais aussi sur 4 bits, sur 16, sur 12, sur tout ce que l'on veut. Certains softs ne savent pas bien gérer tout cela.
Dans le terminal il y a une commande pour afficher les champs tiff et ainsi comparer la complexité à décoder certaines images :
tiffutil -info "nom du fichier.tiff"
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/09/06 1:16, dans <45146eb2$0$25943$ba4acef3@news.orange.fr>,
« Gilles » <gilles.marionot@nordnet.fr> a écrit :
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs
pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces
champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ça explique pourquoi la nouvelle version de Scribus donne des images en
espèce de bichromie 'jaune/vert" pâle ?
Dans le format TIFF il y a aussi énormément de possibilité de variation. Par
exemple une couleur (genre rouge) peut être codée sur 8 bits, mais aussi sur
4 bits, sur 16, sur 12, sur tout ce que l'on veut. Certains softs ne savent
pas bien gérer tout cela.
Dans le terminal il y a une commande pour afficher les champs tiff et ainsi
comparer la complexité à décoder certaines images :
tiffutil -info "nom du fichier.tiff"
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/09/06 1:16, dans <45146eb2$0$25943$, « Gilles » a écrit :
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ça explique pourquoi la nouvelle version de Scribus donne des images en
espèce de bichromie 'jaune/vert" pâle ?
Dans le format TIFF il y a aussi énormément de possibilité de variation. Par exemple une couleur (genre rouge) peut être codée sur 8 bits, mais aussi sur 4 bits, sur 16, sur 12, sur tout ce que l'on veut. Certains softs ne savent pas bien gérer tout cela.
Dans le terminal il y a une commande pour afficher les champs tiff et ainsi comparer la complexité à décoder certaines images :
tiffutil -info "nom du fichier.tiff"
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Christophe Ramananjaona
Le 22/09/06 14:06, dans , « Saïd » a écrit :
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Je l'ai cherché dans Google après en avoir vu parler sur un newsgroup : http://homepage.mac.com/eric.lee/xv
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait expliquer le probleme (difference dans l'algorithme pour ramener une image 16bits vers une image 8bits (necessaire a l'affichage)).
Ce sont bien des images 8 bits en fait.
Christophe
-- Posted via a free Usenet account from http://www.teranews.com
Le 22/09/06 14:06, dans slrneh7ke8.2n1.said@dhcp132-231.enst.fr, « Saïd »
<said@brian.lan> a écrit :
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Je l'ai cherché dans Google après en avoir vu parler sur un newsgroup :
http://homepage.mac.com/eric.lee/xv
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait
expliquer le probleme (difference dans l'algorithme pour ramener une image
16bits vers une image 8bits (necessaire a l'affichage)).
Ce sont bien des images 8 bits en fait.
Christophe
--
Posted via a free Usenet account from http://www.teranews.com
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Je l'ai cherché dans Google après en avoir vu parler sur un newsgroup : http://homepage.mac.com/eric.lee/xv
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait expliquer le probleme (difference dans l'algorithme pour ramener une image 16bits vers une image 8bits (necessaire a l'affichage)).
Ce sont bien des images 8 bits en fait.
Christophe
-- Posted via a free Usenet account from http://www.teranews.com
cramananjaona...
Le 22/09/06 14:06, dans , « Saïd »
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Je l'ai cherché dans Google après en avoir vu parler sur un newsgroup : http://homepage.mac.com/eric.lee/xv
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait expliquer le probleme (difference dans l'algorithme pour ramener une image 16bits vers une image 8bits (necessaire a l'affichage)).
Ce sont bien des images 8 bits en fait.
Christophe
----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
Le 22/09/06 14:06, dans slrneh7ke8.2n1.said@dhcp132-231.enst.fr, « Saïd »
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Je l'ai cherché dans Google après en avoir vu parler sur un newsgroup :
http://homepage.mac.com/eric.lee/xv
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait
expliquer le probleme (difference dans l'algorithme pour ramener une image
16bits vers une image 8bits (necessaire a l'affichage)).
Ce sont bien des images 8 bits en fait.
Christophe
-----
échangez opinions et commentaires dans les forums de discussion.
http://www.usenetgratuit.com/
Tiens, xv pour mac, ca m'interesse. Tu l'as trouve ou?
Je l'ai cherché dans Google après en avoir vu parler sur un newsgroup : http://homepage.mac.com/eric.lee/xv
Essaye de voire si ca n'est pas une image 12 ou 16bits. Ca pourrait expliquer le probleme (difference dans l'algorithme pour ramener une image 16bits vers une image 8bits (necessaire a l'affichage)).
Ce sont bien des images 8 bits en fait.
Christophe
----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
cramananjaona...
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ce n'est pas un très bon point pour les logiciel GNU ça...
Dans le terminal il y a une commande pour afficher les champs tiff et ainsi comparer la complexité à décoder certaines images :
tiffutil -info "nom du fichier.tiff"
Quand j'exécute la commande sur l'image qui pose problème j'ai ça :
Directory at 0x12c968 Subfile Type: (0 = 0x0) Image Width: 800 Image Length: 513 Resolution: 2899.76, 2899.76 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Document Name: "/Users/ramananjaona/Pictures/Scans/tower_bridge_1_small.tif" Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 64 Number of Strips: 9 Planar Configuration: Not planar
Et tiffutil -info sur une image qui ne pose pas problème donne ça :
Directory at 0x12c008 Image Width: 640 Image Length: 640 Resolution: 1200, 1200 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 640 Number of Strips: 1 Planar Configuration: Not planar
Est-ce que c'est parce qu'il n'y a pas le même "nombre de bandes"? ----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs
pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces
champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ce n'est pas un très bon point pour les logiciel GNU ça...
Dans le terminal il y a une commande pour afficher les champs tiff et ainsi
comparer la complexité à décoder certaines images :
tiffutil -info "nom du fichier.tiff"
Quand j'exécute la commande sur l'image qui pose problème j'ai ça :
Directory at 0x12c968
Subfile Type: (0 = 0x0)
Image Width: 800 Image Length: 513
Resolution: 2899.76, 2899.76
Resolution Unit: pixels/inch
Bits/Sample: 8
Compression Scheme: none
Photometric Interpretation: RGB color
Document Name:
"/Users/ramananjaona/Pictures/Scans/tower_bridge_1_small.tif"
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 3
Rows/Strip: 64
Number of Strips: 9
Planar Configuration: Not planar
Et tiffutil -info sur une image qui ne pose pas problème donne ça :
Directory at 0x12c008
Image Width: 640 Image Length: 640
Resolution: 1200, 1200
Resolution Unit: pixels/inch
Bits/Sample: 8
Compression Scheme: none
Photometric Interpretation: RGB color
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 3
Rows/Strip: 640
Number of Strips: 1
Planar Configuration: Not planar
Est-ce que c'est parce qu'il n'y a pas le même "nombre de bandes"?
-----
échangez opinions et commentaires dans les forums de discussion.
http://www.usenetgratuit.com/
Dans le format de fichier TIFF, il existe beaucoup de champs facultatifs pour décrire les couleurs. Il semble donc que Aperçu gère correctement ces champs alors que les softs du GNU ne les gèrent mal ou pas du tout.
Ce n'est pas un très bon point pour les logiciel GNU ça...
Dans le terminal il y a une commande pour afficher les champs tiff et ainsi comparer la complexité à décoder certaines images :
tiffutil -info "nom du fichier.tiff"
Quand j'exécute la commande sur l'image qui pose problème j'ai ça :
Directory at 0x12c968 Subfile Type: (0 = 0x0) Image Width: 800 Image Length: 513 Resolution: 2899.76, 2899.76 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Document Name: "/Users/ramananjaona/Pictures/Scans/tower_bridge_1_small.tif" Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 64 Number of Strips: 9 Planar Configuration: Not planar
Et tiffutil -info sur une image qui ne pose pas problème donne ça :
Directory at 0x12c008 Image Width: 640 Image Length: 640 Resolution: 1200, 1200 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 640 Number of Strips: 1 Planar Configuration: Not planar
Est-ce que c'est parce qu'il n'y a pas le même "nombre de bandes"? ----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
cramananjaona...
Est-ce que c'est parce qu'il n'y a pas le même "nombre de bandes"?
Désolé, autant pour moi, cette image "problématique" avait déjà été redimensionnée, les infos de l'image originale sont celles-ci :
Directory at 0x8 Image Width: 4168 Image Length: 2697 Resolution: 2899.76, 2899.76 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Date & Time: "2006.09.02 17.25.40" Make: "Nikon" Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 2697 Number of Strips: 1 Planar Configuration: Not planar
Est-ce donc un problème de résolution qui serait trop élevée? ----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
Est-ce que c'est parce qu'il n'y a pas le même "nombre de bandes"?
Désolé, autant pour moi, cette image "problématique" avait déjà été
redimensionnée, les infos de l'image originale sont celles-ci :
Directory at 0x8
Image Width: 4168 Image Length: 2697
Resolution: 2899.76, 2899.76
Resolution Unit: pixels/inch
Bits/Sample: 8
Compression Scheme: none
Photometric Interpretation: RGB color
Date & Time: "2006.09.02 17.25.40"
Make: "Nikon"
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 3
Rows/Strip: 2697
Number of Strips: 1
Planar Configuration: Not planar
Est-ce donc un problème de résolution qui serait trop élevée?
-----
échangez opinions et commentaires dans les forums de discussion.
http://www.usenetgratuit.com/
Est-ce que c'est parce qu'il n'y a pas le même "nombre de bandes"?
Désolé, autant pour moi, cette image "problématique" avait déjà été redimensionnée, les infos de l'image originale sont celles-ci :
Directory at 0x8 Image Width: 4168 Image Length: 2697 Resolution: 2899.76, 2899.76 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Date & Time: "2006.09.02 17.25.40" Make: "Nikon" Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 2697 Number of Strips: 1 Planar Configuration: Not planar
Est-ce donc un problème de résolution qui serait trop élevée? ----- échangez opinions et commentaires dans les forums de discussion. http://www.usenetgratuit.com/
Eric Levenez
Le 23/09/06 11:50, dans <45150362$0$20267$, « Ramananjaona Christophe » a écrit :
Désolé, autant pour moi, cette image "problématique" avait déjà été
"au temps" :-)
redimensionnée, les infos de l'image originale sont celles-ci :
Directory at 0x8 Image Width: 4168 Image Length: 2697 Resolution: 2899.76, 2899.76 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Date & Time: "2006.09.02 17.25.40" Make: "Nikon" Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 2697 Number of Strips: 1 Planar Configuration: Not planar
Est-ce donc un problème de résolution qui serait trop élevée?
La résolution ne sert normalement pas car elle ne veut rien dire pour une photo non imprimée.
Tout ce que je peux dire c'est que le TIFF est hyper classique : 3 couleurs (rouge/vert/bleu), chaque couleur est sur 8 bits. L'image est en un seul morceaux (certains vieux softs préféraient plusieurs strips pour une question de place mémoire pour le traitement, ce n'est plus vrai de nos jours). Pas d'espace colorimétrique, pas de compression spécifique, que du classique.
À part un bug du programme de lecture, je ne vois rien d'anormal.
Tu peux toujours essayer de recréer l'image (pour voir si c'est le conteneur ou le contenu qui pose problème) avec une commande du type :
Cela ne doit changer en rien les pixels de l'image, cela change juste le contenant. Après essaye de voir ce que cela donne.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/09/06 11:50, dans <45150362$0$20267$636a55ce@news.free.fr>,
« Ramananjaona Christophe » <cramananjaona...@yahoo.co.uk> a écrit :
Désolé, autant pour moi, cette image "problématique" avait déjà été
"au temps" :-)
redimensionnée, les infos de l'image originale sont celles-ci :
Directory at 0x8
Image Width: 4168 Image Length: 2697
Resolution: 2899.76, 2899.76
Resolution Unit: pixels/inch
Bits/Sample: 8
Compression Scheme: none
Photometric Interpretation: RGB color
Date & Time: "2006.09.02 17.25.40"
Make: "Nikon"
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 3
Rows/Strip: 2697
Number of Strips: 1
Planar Configuration: Not planar
Est-ce donc un problème de résolution qui serait trop élevée?
La résolution ne sert normalement pas car elle ne veut rien dire pour une
photo non imprimée.
Tout ce que je peux dire c'est que le TIFF est hyper classique : 3 couleurs
(rouge/vert/bleu), chaque couleur est sur 8 bits. L'image est en un seul
morceaux (certains vieux softs préféraient plusieurs strips pour une
question de place mémoire pour le traitement, ce n'est plus vrai de nos
jours). Pas d'espace colorimétrique, pas de compression spécifique, que du
classique.
À part un bug du programme de lecture, je ne vois rien d'anormal.
Tu peux toujours essayer de recréer l'image (pour voir si c'est le conteneur
ou le contenu qui pose problème) avec une commande du type :
Le 23/09/06 11:50, dans <45150362$0$20267$, « Ramananjaona Christophe » a écrit :
Désolé, autant pour moi, cette image "problématique" avait déjà été
"au temps" :-)
redimensionnée, les infos de l'image originale sont celles-ci :
Directory at 0x8 Image Width: 4168 Image Length: 2697 Resolution: 2899.76, 2899.76 Resolution Unit: pixels/inch Bits/Sample: 8 Compression Scheme: none Photometric Interpretation: RGB color Date & Time: "2006.09.02 17.25.40" Make: "Nikon" Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 2697 Number of Strips: 1 Planar Configuration: Not planar
Est-ce donc un problème de résolution qui serait trop élevée?
La résolution ne sert normalement pas car elle ne veut rien dire pour une photo non imprimée.
Tout ce que je peux dire c'est que le TIFF est hyper classique : 3 couleurs (rouge/vert/bleu), chaque couleur est sur 8 bits. L'image est en un seul morceaux (certains vieux softs préféraient plusieurs strips pour une question de place mémoire pour le traitement, ce n'est plus vrai de nos jours). Pas d'espace colorimétrique, pas de compression spécifique, que du classique.
À part un bug du programme de lecture, je ne vois rien d'anormal.
Tu peux toujours essayer de recréer l'image (pour voir si c'est le conteneur ou le contenu qui pose problème) avec une commande du type :
