Subject: Re: erdas (sic) satellite image file format

From: [email-masked] (Andrew C Kutner)
Date: Fri, 11 Feb 1994 16:37:42 GMT

If the Erdas file is in the older 7.5 format, I believe the images have only
a 128 byte header on the front of the image, and then some trailing information
that's limited to 1024 bytes.

I worked with those files too long ago to remember the specific numbers, but
I remember that there wasn't a huge amount of extra data added to the images.

If you already know the size, i.e. scanned or satellite, then just play around
with getting rid of the header size... 128,256,512 or 1024 bytes.  It shouldn't
be that difficult because you should see a shift in the picture of XX number
of bytes when you view the picture.  With any image viewer, ex. xv, you can
get a zoom of a section of the image (the upper left) and then use the pixel
numbers to figure the offset.  

The offset is the same for all images under the 7.5 version of the software.

Andy
-------------------------------------------------------------------
Andrew Kutner               Unix Technical Support
[email-masked]     Computing and Information Technology
Voice: (716) 829-2096       State University of New York at Buffalo
Fax:   (716) 645-5972       201 Computing Center, Buffalo, NY 14260
-------------------------------------------------------------------
-- 

-------------------------------------------------------------------
Andrew Kutner               Unix Technical Support
[email-masked]     Computing and Information Technology

---

From: [email-masked]
Date: 12 Feb 1994 20:25:05 GMT

In article <[email-masked]>, [email-masked] (Andrew C Kutner) writes:
|> 
|> 
|> If the Erdas file is in the older 7.5 format, I believe the images have only
|> a 128 byte header on the front of the image, and then some trailing information
|> that's limited to 1024 bytes.
|> 
|> I worked with those files too long ago to remember the specific numbers, but
|> I remember that there wasn't a huge amount of extra data added to the images.
|> 
|> If you already know the size, i.e. scanned or satellite, then just play around
|> with getting rid of the header size... 128,256,512 or 1024 bytes.  It shouldn't
|> be that difficult because you should see a shift in the picture of XX number
|> of bytes when you view the picture.  With any image viewer, ex. xv, you can
|> get a zoom of a section of the image (the upper left) and then use the pixel
|> numbers to figure the offset.  
|> 
|> The offset is the same for all images under the 7.5 version of the software.
|> 
|> 
|> Andy
|> -------------------------------------------------------------------
|> Andrew Kutner               Unix Technical Support
|> [email-masked]     Computing and Information Technology
|> Voice: (716) 829-2096       State University of New York at Buffalo
|> Fax:   (716) 645-5972       201 Computing Center, Buffalo, NY 14260
|> -------------------------------------------------------------------
|> -- 
|> 
|> -------------------------------------------------------------------
|> Andrew Kutner               Unix Technical Support
|> [email-masked]     Computing and Information Technology

The "lan" format does indeed have a 128-byte header.  The images are stored
in 512-byte records.  This means the end of the *.lan file is essentially
zero-filled unless bands*lines*samples + 128 is divides "evenly" by 512.
The information on LAN files is detailed in the ERDAS "Field Guide."
Perhaps Image Alchemy (?) or a similar package deals with *.lan files.
Keep in mind that the file structure dates back to the early INTEL installations.
Some byte-swapping may be necessary to make sense of the imagery (e.g., no. of
bands, lines, ...).

I have some code to read single band lan files using xv-2.21 which is
not very elegant.  However, you can export to other xv image formats.
I have not tried to port it to xv-3.0x(?).  Perhaps someone else has done this?
Depending on interest I make this avail. to one or many.

*Flame on*
I am not an ERDAS fan.  The registration/rectification
routines in ver. 7.5 (lrectify and nrectify) have produced different
results in the resampling stage of the transformation process with
a first-order polynomial fit (approximation) and nearest neighbor
resampling.  It only gets worse with their new product, "Imagine."  Now I
have three "different" images.  Darn if inconsistent information on image
origins didn't make it worse (v8.01).  This will be documented in a report
for a DOE subcontractor in the very near future.  The company was,
oh, so responsive to my queries ;).  Where does product liability begin and end?
Did YOUR results depend on some measure of radiometric fidelity?
*Flame off*

-- 
David N. Fogel
[email-masked]