J'ai un tableau UINT16 NUMPY NUMPY RÉPRESENTANT UNE IMAGE RVB, la matrice est créée à partir d'une image TIF. Le problème est que lorsque j'importe l'image d'origine dans QGIS par exemple est affichée correctement, mais si j'essaie d'afficher dans Python (avec plt.imshow), le résultat est différent (dans ce cas plus vert):
Je pense que c'est en quelque sorte lié à la façon dont Matplotlib gère UINT16, mais même si j'essaie de diviser par 255 et de convertir en UINT8, je ne peux pas obtenir de bons résultats. 
3 Réponses :
Lorsque vous utilisez plt.imshow code> Il y a le paramètre colororm code> que vous pouvez jouer avec, essayez d'ajouter CMAP = "gris" code> donc par exemple plt.imshow(image, cmap="gray")
Aller à votre commentaire, l'image n'est pas codée à l'aide d'un espace de couleur RVB, car les canaux R, G et B ont une plage de valeurs de [0-255] en supposant 8 bits par canal.
Je suis Je ne sais pas exactement quel espace de couleur l'image utilise, mais les fichiers TIFF utilisent généralement CMYK qui est optimisé pour l'impression.
D'autres espaces de couleur courants à essayer incluent YCBCR (YUV) et HSL, mais il y a beaucoup de variations. de ceux qui ont été créés au fil des ans, les technologies de matériel d'affichage et de diffusion vidéo ont avancé.
Pour convertir toute l'image en un espace de couleur RVB, je recommanderais le OpenCV-Python PIP Package. Le package est bien documenté, mais comme exemple, voici comment vous convertirez un tableau numpy img de yuv à rgb:
Si j'essaie de normaliser l'image, je reçois de bons résultats:
Pour chaque canal: Image [I, ::] = Image [I, ::] / Image [I,: ,:]. Max ()
Cependant, certaines images semblent plus sombres que d'autres:
Au lieu de cela si je normalise l'image divisant par 65535 (puisque ils ont codé comme uint16), je reçois de très petites valeurs de pixels afin qu'ils soient presque complètement noirs
En fait, j'ai vu que dans QGIS, les différents canaux RVB n'ont pas la même plage, r = [0, 235], g = [0,363], b = [0,263]
Avez-vous essayé de diviser R avant 235, G de 363, etc.? Obtenir toujours la sortie trop verte?
Vous divisez par 256, pas 255 techniquement