Distinto tamaño en bytes de las bandas Landsat

Foro de usuarios de MiraMon en castellano
Respon
JSB
Entrades: 2
Membre des de: dv., 19 nov. 2021, 09:37

Distinto tamaño en bytes de las bandas Landsat

Entrada Autor: JSB »

"¿Por qué, tras una importación de una imagen Landsat CEOS, los ficheros IMG no tienen todos el mismo tamaño si todos tienen el mismo número de columnas y filas y todos tienen un mismo número de bytes para cada uno de los valores espectrales grabados en cada píxel?"

Muchas gracias.
XavierPons
Entrades: 18
Membre des de: dj., 02 juny 2011, 10:02

Re: Distinto tamaño en bytes de las bandas Landsat

Entrada Autor: XavierPons »

En el caso de la importación en MiraMon, se aprovecha para comprimir las bandas de la imagen para que ocupen menos, y de ahí que los ficheros sean menores que lo que dice la fórmula ncol*nfil*bytes_por_pixel en la inmensa mayoría de los casos (puede haber situaciones muy raras en que no sea así, pero como digo son muy raras). Esta es la razón. No te “mareo” ahora con tipos de compresión (con pérdida, tipo JPEG, JPEG2000 típico, ECW, MrSID, etc, o sin pérdida, tipo RLE, RLE extracomprimido e indexado, LZW, etc), porque tal vez ya conoces estos aspectos; si no fuera así y te interesa, me dices y te lo completo.

En todo caso, puedes siempre saber si un fichero está comprimido o no mirándolo en el Gestor de Metadatos, en la pestaña de Información temàtica. Te lo marco en rojo para un fichero que no es una imagen de TD, sino un MDE, pero tanto da:
Compresion_en_GeMPlus.png
Pot otra parte, la imagen de la banda 6 en TM, por ejemplo, correspondiente a la región espectral del térmico tiene en realidad menor resolución espacial (120 m versus 30 m de las otras); ello provoca que ocupe 120/30=4 veces menos linealmente pero 16 veces menos en superficie (donde hay 1 píxel de 120 m x 120 m de térmico caben 16 píxeles de 30 m x 30 m en el resto de regiones espectrales); para que “encajen” los píxeles de 120 m en los de 30 lo que se hace es “repicarlos”/”subdividirlos” en píxeles ficticios de 30 m, pero como los 16 píxeles repicados (reescritos) a 30 m dentro del espacio geográfico del píxel original de 120 m tienen el mismo valor, cuando se somete el fichero a compresión, el algoritmo encuentra muchas repeticiones, puede comprimir mucho más, y por eso ocupa mucho menos.

Si quieres jugar un poco más puedes usar la aplicación IMGIMG (“Herramientas | Mantenimiento de ficheros | Conversión y compresión....”) desde donde puedes reescribir los ficheros IMG en formato descomprimido:
IMGIMG.png
y podràs ver que entonces el tamaño en bytes es exactamente el de la fórmula; para saber el tamaño sin aproximaciones a kbytes o Mbytes o Gbytes de un fichero puedes hacerlo con el botón derecho del ratón y pidiendo “propiedades”; en el siguiente ejemplo, para un fichero cualquiera, te muestro, en rojo, dónde hay que mirar:
Tamanyo_de_un_fichero.png
Cordialmente,
Xavier
Respon