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

20040913: ldm-mcidas image decoder pnga2area (cont.)

>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200409071813.i87IDevq001014 ldm-mcidas pnga2area

Hi Hsie,

I have returned from my travels in Brazil, and have started looking at
the pnga2area problem you reported last week.  The working hypothesis
at the moment is:

- the v2003 pnga2area does not truncate the file into which image
  data will be decoded.  This is not a problem when decoding into
  a file whose name is a function of the date and time as it is
  unlikely that the file will already exist when the decoder is
  run.  It is a potential problem when using McIDAS routing table
  concepts because the set of files being used _will_ exist after
  enough have been decoded (circular namespace).  Without truncation,
  the output file will keep the size of the existing image it
  is overwriting.  This means that the file size can do nothing
  but stay the same size or grow; they can never shrink.

- at some point during the week of September 1, a slug of "bad" Mollweide
  WV images were sent in the Unidata-Wisconsin datastream.  These
  files decoded to a size of 33556032 bytes, and there were at least 10
  of them.

The two parts of the hypothesis would explain why images being decoded
using routing table concepts are larger than the same image decoded
using user-specified naming.

I have built a new pnga2area that specifies truncation of files being
written, and am using it on a test machine in my office.  As images are
received, it will become evident if the hypothesis above is correct or
not.  I will keep you informed.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.