Hi Mike, re: > What I meant was, do you know where SANDWICH cuts off plotting the IR > band? It's not plotting the entire range, I presume above some brightness > temp, but I wasn't sure where that was. IF this makes it onto our page, > we'd like to include some information about it so that's why I was asking. The HELP for SANDWICH says what is used by default for the IR BREAKpoints: HELP SANDWICH SANDWICH -- Combines image and basemap into multi-banded RGB image SANDWICH vis ir dest <keywords> Parameters: vis | source ADDE dataset name and position; specify as alias.position or group/descriptor.position; to use the default position, either enter "0" or omit the .position portion (no def for alias or group/descriptor; def=0 for position) ir | source ADDE dataset name and position; specify as alias.position or group/descriptor.position; to use the default position, either enter "0" or omit the .position portion (no def for alias or group/descriptor; def=0 for position) dest | destination ADDE dataset name and absolute position; specify as alias.position or group/descriptor.position; only positive integers are valid for the position number Keywords: IReu= | name of enhancement table to apply to infrared image (def=SANDWICH.ET) NAVele= | number of elements between each navigation calculation; the range is 1-640 where higher numbers increase speed by decreasing the number of calculations, but also result in lower image quality (def=5) BREAKpoints=temp_warm temp_cold | temperature values to apply IR enhancement (def=265 190) Remarks: Both visible and ir datasets must be 1 byte By letting the end-user specify the BREAK= keyword, one can change the range of BRITnesses used from 265 - 190 to whatever one wants. re: chance that SANDWICH will become a core McIDAS routine is unknown > That was my impression, and I'm not either. Figured it wouldn't hurt to > say that request out loud. :-) re: what it takes for an XRD command to make it into the Unidata McIDAS distribution - have to test the command on a variety of platforms because SSEC does not > Understood. re: makefile actions are hard links, not copys > Oh, that's good to know as well. re: HELP will also list REMark lines from McBASI scripts > I did not know HELP would do that, yes these were the comments I was > referring to. Yup, this has long been a feature of HELP: HELP HELP HELP- Lists on-line help for McIDAS commands HELP command HELP McBASI_command Parameter: command | McIDAS command name McBASI_command | a McBASI command name Remarks: re: Rick Kohrs, who is THE master of cool McIDAS displays > Ah, cool indeed. Yup, I've been generating "true color" displays from NOAAPort SCMI imagery ever since your email yesterday :-) re: > FWIW I spent very little time working with ABITRUCOL.MCB so far. I'm sure > all these things are easily addressed, I just didn't get that far. But for > any future internet travelers browsing the support archives, I could see > these being things that might trip people up, so figured they might be > noteworthy. Absolutely noteworthy! re: > ABITRUCOL is a McBASI script that executes McIDAS commands to copy > > bands 1, 2, and 3 from an ABI image, manipulate them into the same > > resolution, create an approximated green band with IMGOPER, and then > > use the RGBDISP command to display the ABI natural true-color RGB image. > This is about what we do now, only with the COMBINE command instead of > RGBDISP as I believe that did not yet exist when I was building the RGB > products. Otherwise the core commands are a relatively similar process. Correct, RGBDISP did not exist when you first started producing your "true color" content. re: > While creating the true-color RGB image, the script runs IMGCOPY, > > IMGREMAP and IMGOPER commands that overwrite Area files 4501-4540 > > (AREA4501, AREA4502, ..., AREA4540). To change the Area file numbers > > or make any other changes (e.g., change the default dataset or station), > > copy the file ABITRUCOL.MCB from ~mcidas/data/ to your > > $HOME/mcidas/data/ directory and edit the file. > > > > Agree this would be the plan if I intend to use ABITRUCOL.MCB directly at > all. Note that SSEC assumes that McIDAS is installed in the 'mcidas' account, AND other accounts use the installed code. In fact, their 'mcidas' startup script does not allow the user 'mcidas' to run McIDAS. I change that for the Unidata McIDAS distribution since I need to be able to run McIDAS-X and McIDAS-XCD as the user 'mcidas'. For SSEC's XCD use, they would have the user create an account named 'oper', and then run the XCD stuff from there. I always felt that this was overly burdensome, so I changed it. re: ABITRUCOL working with local dataset - I used this yesterday by specifying a local dataset instead of one on a remote server > OK, excellent. re: beware of name clashes when using the AREAnnnn naming convention > SAME! I remember when I was learning McIDAS and I came to this > realization, I may have fallen out of my chair. If only one could > reference AREA files with different names (e.g. GOES16.0001, GOES17.0001), > that alone would open up so many other options. Ah well, is what it is I > suppose. You _can_ name your files anything you like for READ ADDE datasets. The problem is for WRITE/output datasets. Russ Dengel and I chatted about this a number of years ago since I had visualized a way around this restriction, but I never took the time to implement my "solution". re: I am always interested in what you are doing with McIDAS! > Well, hopefully we'll be doing more with it soon. ;) Two thumbs up!! 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: OPE-279047 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.
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.