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

20000622: GOES Sounder DPI for Unidata

>From: Gary Wade <address@hidden>
>Organization: NOAA/NESDIS/ORA/ARAD/ASPT at UW-CIMSS
>Keywords: 200006221816.e5MIG0T26508 Unidata-Wisconsin CIMSS products

Gary,

>       Great to see that the GOES Sndr DPI are making their way out onto the
>Unidata data flow.

They go live next Wednesday.  I have been conversion with a few users who
took the opportunity to update their LDM setup this week in preparation
for the new products and datastream image file compression changes that
are part of this addition.

>You raised some good points; I've tried to answer
>them below (with the ***s).

OK, thanks.

>       One comment came to mind from the first look at your Unidata-Wisc
>datastream page, with respect to the CIMSS GOES products.  The profile
>(PW, LI, CAPE...) and cloud product coverage does vary (considerably)
>beyond the US ("the eastern 48").  Your examples selected for CTP and
>PW, at 20Z on 15 June 2000, unfortunately show minimal coverage for the
>"floater" Pacific (G-10) and Atlantic (G-8) sectors.  At other times,
>the coverage would fill the screen much better.

If you have GIF (tm) that show the full coverage, I would love to use
them in place of the ones I grabbed off of your (CIMSS) web page.

>(Sometimes better,
>sometimes worse...).  This coverage consideration also does apply
>equally for LI and CAPE.

OK, this is good to know.  I should probably add a sentence or two to
our data page that makes note of this.

>Also, if one does not have interest in those
>oceanic regions, one can display the DPI rather regularly (each hour)
>just over the US, for more optimal viewing.  So, although we started out
>initially with that wide all-sectors display of the PW on our CIMSS
>page, we did add a US-only coverage (also at a somewhat better
>resolution as well) which might seem more desireable for many users.  

If the wide coverage contains the US coverage, it would be best to have
it(them) as examples and as the products in the datastream.  The blank
space is not an issue for distribution since the PNG compression being
used is very efficient in compressing blank areas down to zero length.

>       Please keep those comments, and any feedback, coming.  Thanks.

Will do.

>> o change the band numbers to be unique to the products (this is for
>>   GEMPAK folks)
>> 
>> o flesh out the memo field in the AREAs so that McIDAS users have
>>   something to read when they do IMGLISTs
>
>***  Some, but not all, of the DPI do have valid, informative memo
>fields (PW, LI, CAPE...).

When I looked at what we were getting, I was struck by there only being one
product with a really descriptive memo field.  Since I was having to do
an IMGCHA for the BAND numbers, I simply decided to take the opportunity
to change and regularize the memo field text.  I can change the text
to anything that you (CIMSS) wants, so let me know.

>I've asked TonyS and ChrisS to add memos to
>their CTP and ozone DPI areas.

OK.  I will try to take a look at the images I can access with ADDE
and check them out before IDD transmission starts on Wednesday.

re: Also, it seems apparent
that the graphics tables in place when the GIFs (tm) were produced are
specialized.  Use of the default/graphics color table makes the VIRT
overlays look pretty bad.

>***  Yes, the graphics levels would need to be set to black for 4, and
>to white for 7, for the simplest and most legible display.  Within our
scripts, I've always set those levels (and in McIDAS, although I've
>usually left levels 1-3 as defaulted, I change the higher ones
>routinely, with my own GU default table).  I have now added this info
>(col lev 4 black; 7, white; frame 480x640) to the VIRT section of the
>readme file in the dpiets directory.

OK, fair enough.  I may need to produce a McIDAS graphic table that can
be used on the images through our interfaces.

re: It would be useful to find out the environment in which these
enhancements were created (i.e., how many image colors the session that
the GIFs have, etc.).

>*** The image color levels situation shapes up as follows.  The default
>for (.mcidasrc) -imageColors is 48 when running "mcenv", which is how we
>do set up our McIDAS to run from crontab'd scripts.  For the DPI, which
>are only 1 byte deep data, we actually preferred the 48 levels for the
>web displays.  The thought there was that, for the PW for example, we
>only show 7 distinctive color groups; within any color, we were then
>satisfied (and confident) to only show a few more gradations.  The
>coarser (blockier) color resolution also seemed to allow one to see more
>definitively where the, say, 26-28mm, region is, versus seeing just a
>smoother section throughout the upper 20's portion.  We did consider
>these "effects" some time ago; your input and experience with this might
>convince us to re-consider.  In contrast to the DPI display, we do set
>the color levels to 128 for the "radiance" imagery (all or individual
>bands) as shown on the web page, where we are looking at much higher
>fidelity imagery.

OK.  I had worked around to the realization that 48 image colors were
most likely being used when I worked on reproducing an OZONE.ET
enhancement (there wasn't one on thbe FTP site).

I will let folks there know about any comments we receive about the
products.  I, for one, can tell you that I find them to be a very
exciting demonstration of what can be done by all of that fabulous
satellite imagery that the majority of synoptic meteorologists use
more-or-less as wallpaper.

Tom