Jump to content
PDS Geosciences Node Community


  • Posts

  • Joined

  • Last visited

Everything posted by Allendej

  1. I wonder if anyone would have a good book recommendation for getting stuck into ENVI+IDL coding with a focus on this type of data? Has anyone self taught with a particularly useful book?
  2. Thanks so much Frank for helping me find a way around this problem. I have now avoided calling select_summary_params entirely by taking the subscripts of the basic parameters from lvl (which just separated basic and advanced): selected_params=where(lvl eq 1, lvlsel) Elyse
  3. Hello, This is largely an IDL question concerning the new release of 2014 CRISM summary parameters in the CAT v7.3.1, so I'm not sure if it's appropriate here. I am working with: CAT_ENVI/save_add/CAT_Programs/Supplementals/select_summary_parameters.pro CAT_ENVI/save_add/CAT_Programs/Event_Handlers/mro_crism_summary_params_2014_event.pro Is there a way to bypass the control widget in 'select_summary_params.pro' and simply generate the default selections (basic products) without waiting for "OK" to be pressed? I want to link several CAT pre-processing steps together and don't require the widgets, but I am finding it difficult to manage widgets and events in these pro files because I am a beginner with IDL. I have looked into all the available IDL help files, but am still having trouble getting around this. I think my main problem is understanding where/how the program stores the event that the OK button is pressed in 'select_summary_params.pro'. I can see the structure of the widget being created in the second half of the pro file, then it is handed off to xmanager ~ line 236 Then an event, such as a button press, must occur in order for its uvalue to be returned to the event handler in the upper portion of the code ~ line 28 I only require the possibility of 'OK', because I don't want any other selections to be made or changed. But if I manually set uvalue to 'OK', it's not linked to any event ID, so I don't think it is recognized in any case. Elyse
  4. Hello, When using the CIRRUS corrections within CRISM CAT I obtain an error - part of which is "no good data found". I know that CIRRUS corrections are generally unnecessary with TRR3 data, but the extra pre-processing really helps further on in my analysis. The destriping step is performed correctly, and I obtain an output image, so data exists. I have read the help file and taken a look at the .pro files for these corrections so that I can see what is going on, and varied my input parameters (spatial/spectral kernel size - yet always leaving spectral smoothing at 0) but to no avail. As I understand, in order to flag a spike neighboring spectral bands must both be higher or lower than the current band being examined. To remove these spikes, the spectrum at each pixel is divided by the mean spectrum of each band. The spectrum at each pixel is also divided by an albedo image (the average spectrum across all pixels). I am guessing that somewhere during this division process is where this error occurs, but the fact that a valid destripe image is used as input for the despiking makes me confused about the "no good data" message. I should also say that I don't get this error for all images, only a few. For example, FRTC815 gives this error. But FRT3E12 does not. Elyse
  5. Hello, I notice that when I use the CAT 7.2.1 - Map Utilities - Project Single Cube Data tool, I obtain a different result than when I use the Build GLT tool in ENVI, with: X Geometry band = Band 5 of the associated DDR Y Geometry band = Band 4 of the associated DDR according to the instructions here on slide 23. http://crism.jhuapl.edu/data/CRISM_workshop_2009/docs/agenda/CRISM_Workshop_090322_Nili_Fossae_Walkthrough_FPS.pdf Looking at the IDL projection_event.pro, I see that the lat and lon keywords are defined as follows: ; Pull some planes from the geofile lat = envi_get_data(fid=geofid,dims=dims,pos=3) lon = envi_get_data(fid=geofid,dims=dims,pos=4) Should this be bands 4 and 5 (as in the walkthrough slides) rather than 3 and 4? The filename I am using is: /home/Raw/frt00003e12_07_if166l_trr3_CAT_corr_SUM_classified_noProj.img I know in find_geofile.pro that an automatic search is done for the ddr associated with the default trr3 name, but I'm not sure if it would find the ddr associated with mine as the filename has been altered from the standard CAT convention. Essentially I am wondering which projection method is more correct. Regards, Elyse
  6. Hello, This is a very simple question, but I'm having trouble finding any information about this. Am I able to download the CRISM spectral library in order to perform spectral matching for spectra I have no prior knowledge about? I see that crism library data can be downloaded as a zip or tar file, but I am not sure how to handle the .tab files so that ENVI can see them as a library.
  7. Ah I see. Thank you. One more question, relating to TRDRs - do you know the approximate number of images that have been studied so far, or perhaps how many images are available? I know that Carter et al. (2014) submitted an abstract to the LPSC this year in which they conducted a survey of 2900 images (http://www.hou.usra.edu/meetings/lpsc2014/pdf/2364.pdf), and I wondered why this number was chosen as I read elsewhere that about 10000 images were taken in MROs PSP.
  8. Hello, I have just downloaded t0902_mrrsu_05s138_0256_1.img covering Gale crater, and just have some general questions: - Is the coverage for all mrrsu* products typically about 40% of a tile? I wasn't expecting such a large amount of missing data. - Is there any reason why each image strip seems to be individually normalised, but only in some products? For example, the IRAC product seems to have consistent values across the mosaic (I can clearly see the crater from the image), however, other products (mainly single band images, eg R440) appear to have each image strip with different ranges across the mosaic, as do the mrrif* images.
  9. Hello, I'm trying to locate mineral clusters in CRISM I/F data using a Self-Organizing Map, but ultimately, even though I normalize the data prior to running a SOM my output clusters correspond with bright and dark areas. I am working with GRASS and R, so here are my processing steps: - import CRISM data into R, each pixel contains a vector of 254 values corresponding to the I/F values in the first 254 image bands. I am now working with a matrix, of n rows (number of pixels in image) by 254. This CRISM data has previously been though the CAT pre-preprocessing pipeline. - Calculate the mean value of each pixel, so that each pixel is now a residual vector (difference of each band from the mean spectrum of the pixel) - This means that I can better compare pixels to one another, as they are not affected by differences in brightness (are not offset from one another, as they would be if I used the mean spectrum of the image). - normalize each vector component [0,1] - use this new residual matrix as input into a 50x50 SOM. - The output codebook data from the SOM I simply classify with hierarchical clustering (for the moment) so I can see basic separable regions. (This basic number of clusters I estimate using a distance/similarity matrix.) Unfortunately, despite the above steps these clusters still correspond to bright/shadowed areas, in the majority of cases. I was hoping someone might be able to offer some suggestions as to why this might be?
  10. Hi Frank, Thanks very much for your reply. I know there is a list of detection thresholds for the OMEGA parameters in Poulet et al. (2007): 'Martian Surface Mineralogy from OMEGA/Mex', but I was wondering if there was such a list available for CRISM too? I know their formula are in Pelkey et al. (2007): 'CRISM Multispectral Summary Products' but I'd like to threshold each summary product with a realistic detection value - or is ~0.05/~0.1 applicable to most of the parameters?
  11. Hello, I've created some CRISM IR summary products using the CAT and am visualising them in combination with a HiRISE image. To highlight areas with the largest spectral response, in OLINDEX for example, I have read that typically stretching is performed using zero as the minimum realistic value and the 99th percentile as the maximum. The range of the OLINDEX parameter is very small: Minimum -0.107, Maximum: 0.084, so Adjusted Min: 0, Adjusted Max: 0.043. I was wondering what the typical expected values for these parameters are. What constitutes a significant response? For example, my 99th percentile value is 0.043 but this might still be a very small response compared with other areas. Regards, Elyse
  • Create New...