[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000801: AREA file endianess, lw3toa vs pnga2area

>From: David Wojtowicz <address@hidden>
>Organization: University of Illinois
>Keywords: 200008011452.e71EqgT12781 ldm-mcidas Unidata-Wisconsin lwtoa2 
>pnga2area endian

David,

>I've gotten pnga2area set up and working to decode the conventional
>imagery from the MCIDAS stream.

Very good.  I trust the process was not arduous.  By the way, as a
follow-up to our exchange yesterday, I should point out that pnga2area
has a lot of flexibility in naming output files.  One can use the
header information in the broadcast to name the files, of course, but
one can also use pnga2area capabilities directly.  For more
information, please review the pnga2area man page or run pnga2area with
no command line arguments.

>However, I've noticed that under linux
>pnga2area writes out files with the opposite endianess of the linux
>version of lw3toa.

>Here are the first few bytes of the header of files decoded with lw3toa
>and png2area under linux. (as output with 'od -t x1')
>
>lw3toa:
>0000000 00 00 00 00 04 00 00 00 4a 00 00 00 
>
>png2area:
>0000000 00 00 00 00 00 00 00 04 00 00 00 4a 
>
>As you can see, the linux output of lw3toa is little endian.

lwtoa3 writes AREA files in the endianess of the machine on which
it is running.

>(under HP-UX for example, lw3toa writes out big endian files).

Right.

>png2area
>writes out big endian files under linux now too, which seems to make it
>more consistent.

pnga2area maintains the endianess of the image that it uncompresses.

>I've presumed that big-endian is correct and the
>linux lw3toa was doing it backwards.

The AREA file standard allows both big and little endian forms of the
file, so both are correct.

>The issue had first come up from us when we migrated from a hp-ux host
>as our ldm server to a linux host.   In doing so the endianess of the
>mcidas area files changed.  We run image display programs such as garp,
>wxp, etc on both kinds of hosts.

GARP (GEMPAK, that is) should not care about the endianess of the
images.  I can't say for sure what WXP is doing, but I can tell you
that my last impression of WXP's support for the AREA file format was
that it was incomplete.  Mind you, I developed this impression a number
of years ago.  I have no idea what Dan has done to the code since
then.

>We found that some programs could
>deal with files in either format, while others could not.

The packages that can not display both big and little endian AREA
file images are not supporting the AREA file standard.

>To deal with
>the problem, I wrote a converter program that switches the endianess of
>the area files so that the ones produced with lw3toa under linux would
>work everywhere.  In switching to pnga2area I just discovered that the
>files were already "correct" and my program was now making it backwards
>so I have discontinued its use.

Please remember that pnga2area does not specify the endianess of the
output image.  It simply keeps the endianess of the original image
before the PNG compression.

>The change in endianess in switching from lw3toa under PC linux (and
>presumably alpha boxes) to pnga2area may cause potential problems for
>others I would imagine.

So far, I have not heard concerns about file endianess from any other
users.

>Is big-endian the correct format for area files? Or does the AREA file
>format allow both and all programs should be prepared to deal with both
>kinds?  Perhaps you can clear this up for me?

The AREA file format allows for both endianesses.  Programs that display
AREA file images should be updated to support the AREA file standard.

>Thanks!

No problem.

Tom