ftp Landsat TM imagery that are in ERDAS, import them in GRASS

Virginia R. Hetrick IARGRAF at MVS.OAC.UCLA.EDU
Sat Sep 24 15:10:00 EDT 1994


The basic answer for FTPing anything other than files that are
absolutely known to be plain ASCII text is that you treat them as
binary, i.e., you issue the BINARY command inside FTP before you
issue the GET, PUT, MGET, or MPUT command.

In the specific case of imagery, think of things in the following way:

Recalling that, in general, imagery appears to the naked eye as garbage
text, you need to be able to have a particular pixel take on a value
from 0 to 255 or 1 to 256 or some other range of values.  When the image
is stored by the program that creates its digital format, it's just like
having a long string of typed characters where each character represents
one pixel.  If I were typing this on a PC and I typed the following
line (sort of like one scan line in my image):

 123456789

I would have represented each of those pixels having the following
values in order:

  31 32 33 34 35 36 37 38 39

These are pretty easy to represent so you can read them.  What happens
though if you have a pixel that is supposed to have a value of say 9
or 13?  The answer is that hardware and software can represent those
numbers just fine but people have considerable difficulty "reading"
them.  Computers can exchange information even though you can't read
it; dissimilar computers can do the same.  That's one of the primary
reasons for having what are (not affectionately) referred to as
character sets.  The character sets contain characters that the
software can interpret but which you can't read, per se.  However,
any image processing software that is programmed to read the image
in should be able to "descramble" this so you get the pixels you want
in the right places on your screen.

Getting a little deeper into this, there are text editors available for
PCs (Kedit is one) and other computers that will allow you to show
these values in what is referred to as "hex" which is short for
hexadecimal, or a number system with base 16 (rather than 10).  Hex
representation of the 13 or the 9 in the previous comment is x'0c' or
x'09'.  This allows everything between 0 and 255 to be represented by
a specific hex number.  If your particular image processing system
requires pixel values to range between 1 and 256, then it will usually
add 1 to the values as they are read in.  If your image processing
system requires the values to range betweewn -127 and +127 as one
of the systems I've used does, then you'll find that image processing
system takes care of the range conversion automatically as well.
The digits in hex are 0123456789abcdef (I bet you never know an a
could be a digit ;-)

This may be a little elementary, but I sensed a question asking "How
does this work" as well as the specific information about ERDAS and
GRASS (which will have to be answered by somebody who works in both
those packages.

HTH.

v(Usually a GRASS lurker)h



More information about the grass-dev mailing list