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

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re: I got your second email too, batch file received.

Very good.

re: test enhancement

> I got that too, I'll check it out.  And yes, I noticed the IR images
> (band 13 at least) appear substantially dimmer than what I've been
> plotting in python.

I am currently directly mapping raw counts (CMI 12-bit values) onto
brightness as:

(0:4095) -> (0:255)

McIDAS image displays use brigtness, and, assuming I haven't mucked
something up with the mapping, the range of raw counts is something
different than 0:4095.  I will be checking my code (again) to make
sure that I haven't mucked something up, but spot checks of 
values at random points in an image (interrogate the image using
IMGPROBE) suggest that my mapping is what it should be.  If this
really is the case, it means that there is a problem with the counts
in the NOAAPort-distributed GOES-16 images.  I can check this by
comparing against the GRB-delivered GOES-16 images for the same band
at the exact same time and comparing brightness that should be the
same.  This is what I was alluding to in a previous email.

re:
> One thing I tried today was to apply the
> IRTEMP.ST stretch table, and that seemed to get it close.  But I'm
> concerned that by stretching the data as such that I'd be losing data
> quality if that makes sense.

If the range of raw counts is less than the full 0:4095 range, then
stretching the values will not result in a loss of of data quality.

re:
> I'll try this ET the next time I get a
> chance and see how that looks...  But why are they dimmer in the first
> place?

Why?  TBD...

re:
> Thanks, Tom.  I'll have more time to get my hands dirty next week, and
> I'll be sure to keep you posted.

OK, sounds good.

re:
> I do have one more question.  Does this version of McIDAS handle the
> GOES16 Level 2 derived products coming over NOAAPort?

No.  As soon as I get the image servers finished, I'll be focusing
on servers for the products.

re:
> It looked like
> that was implemented with SSEC v2017.1, along with support for the GLM
> data (if I can ever get my hands on that).

The SSEC servers handle both the GRB-delivered ABI imagery and CSPP GEO
AFIT created products.  They do not handle the images or products being
sent in NOAAPort since the internal netCDF formats are totally different
and their servers rely heavily on the files being named a very particular
way (their servers extract a LOT of information from the file name, and
I don't have that luxury with files that will be created by end-user
created processes).

re:
> I hope I'm not asking too
> much, but I'm sure you'll agree this data is amazing, and we
> eventually want to make available everything GOES16 has to offer.

Yup, so do I :-)  I want to work on one thing at a time and get things
right...

re:
> Thanks again!

No worries.

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: JGN-249914
Department: Support McIDAS
Priority: Normal
Status: Closed
===================
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.