[McIDAS #VYG-127238]: png-compressed AREAs doesn't pick up filename from comment card

Hi Tyn,

re:
> No, no mods from my side. All (new) functionality was in the area2png
> by default (mcidasx-ldm distribution from Unidata).

OK, sorry for my misunderstanding...

re:
> Funny it doesn’t pick up the info from SATANOT & SATBAND to generate the
> filename using the new "Output PNG pathname mask" functionality. Do these
> debug messages tell u anything:
> ---
> > Jun 15 16:50:47 DEBUG: in GetFileName
> > Jun 15 16:50:47 DEBUG: mask: 31
> > Jun 15 16:50:47 DEBUG: band: 5
> ---
> ?
> 
> This gets pretty ugly because now that I have to process band-by-band
> (for the png-compression step later) I'm getting duplicate filenames with
> the "Output PNG pathname mask" functionality missing, and consequently band2 
> is overwriting band1.
> 
> Here is the area2png help:
> 
> Usage: ./area2png -f AREAfile <-a SATANNOT> <-b SATBAND> <-vxl-> PNGfile
> Where:
> -a SATANNOT  McIDAS SATANNOT pathname (def: /home/mcidas/data/SATANNOT)
> -b SATBAND   McIDAS SATBAND pathname (def: /home/mcidas/data/SATBAND)
> -f AREAfile  Input AREA pathname (no default)
> -h           Print the help file, then exit the program
> -n           Echo the output file name to stdout (def=no)
> -l logname   Log file name (default uses local0; use '-' for stdout)
> -v           Verbose logging
> -x           Debug logging
> Positionals:
> PNGfile      Output PNG pathname mask (no default)
> 
> 'PNGfile' may contain 'replaceables':
> \BAND - band information from SATBAND
> \RES  - resolution information from SATBAND
> \SAT  - satellite platform info from SATANNOT
> 
> and 'strftime' style day/time specifiers:
> %Y    - image year       [CCYY]
> %m    - image month      [MM]
> %d    - image day        [DD]
> %j    - image Julian day [JJJ]
> %H    - image hour       [HH]
> %M    - image minute     [MM]
> etc.
> 
> Example Invocation:
> ./area2png -l - -f /data/ldm/mcidas/AREA0170 \SAT_\RES_\BAND_%Y%m%d.%H%M
> 
> might expand to the equivalent:
> ./area2png -l - -f /data/ldm/mcidas/AREA0170 
> GOES-8_IMG_8km_6.8um_20000511.2000
> 
> Note the careful choice of wording "might expand".

My judgment is that the shell is interpreting the '\' character so it is
not being passed along to the routine.  The invocation from the
command line or a script should escape the escape character.  This
would look like:

./area2png -l - -f /data/ldm/mcidas/AREA0170 \\SAT_\\RES_\\BAND_%Y%m%d.%H%M

For instance, here is a snippit of code that is run on the images being
created-for and sent in the IDD UNIWISC datastream:

#!/bin/ksh

 ...

#
# Create the PNG compressed AREA product
#

file=`area2png -n -f $HOME/mcidas/data/AREA${anum} -a /home/ldm/ldm-mcidas/etc/S
ATANNOT -b /home/ldm/ldm-mcidas/etc/SATBAND "pnga2area ${qn} ${dialprod} ${adef}
 \\SAT \\BAND \\RES %Y%m%d %H%M"`

Note how the SAT, BAND and RES replaceables are doubly escaped.  The first
escape says to ignore the meaning of the second, so what is passed to
area2png is '\SAT', '\BAND', and '\RES'

Please try modifying your script to doubly escape the replaceables and let
me know the result.

re: area2png does not understand multi-banded images
> Mmm, pity. Certainly makes my cronjob less lean :-(

Yes, I agree.  The original objectives of area2png were pretty simple and
straightforward.  Supporting single-banded images made the code nice
and simple.  Adding in support for multi-banded images would be nice,
but my impression is that the code would be complicated (and, therefore,
prone to errors).  The modifications needed to support direct serving
of the PNG-compressed images in McIDAS would also be "interesting".

As I put together the Unidata v2010 release, I will review the PNG uncompression
code to see what it would take to incorporate support for multi-banded
images.  In the meantime, I suggest proceeding with using single-banded
images for the Mongolian archive.

re:
> Just wanted to tell you how happy we are with your png-compression:
> File sizes typically reduce to 40-50%!!!!

We ran lots of comparisons to evaluate different compression techniques.
Overall, we found that the PNG approach was the best, and using bzip2 was
second best.  I have not revisited this decision in over a decade, so
the comparisons today might be different.  Also, I did not spend a lot
of time trying to develop PNG filters that would significantly improve
the compression.  One of the main reasons for not pursuing this approach
was the expectation that the needed filters would be satellite platform
specific and/or wavelength channel specific, and it would absolutely
preclude effective compression of multi-banded images.  If you are interested
in learning more about the use of filters (might be called something different),
I suggest reading through the PNG web site.  The use of the correct filter
can result in spectacular compression ratios!


Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: VYG-127238
Department: Support McIDAS
Priority: Normal
Status: Closed