John Christian

Hello Sehaj, I've taken a look into the first anomaly that you see, and I think I have an explanation. What's happening here is actually an artifact of the summary product flattening that was applied to the TER and TRDR datasets. For each parameter, the flattening algorithm is designed to adjust the median values of each column in sensor space to match the median value of the parameter across the entire scene, in order to minimize the effects of column-dependent noise. However, this scene has three distinct regions (CO2 ice, magenta in the MTRDR, H2O ice, green in the MTRDR, and ice-free, black in the MTRDR), which causes this algorithm to break. In this scene, it looks to me like the flattening algorithm generally adjusted all columns to have the same median parameter values as the CO2 ice region, which is why most of it appears black in the default color stretch. The magenta "wedges" you see in the projected TER/TRDR images are pixels viewing CO2 ice, but where most of the column has ice-free pixels, so the parameter values in these wedges were significantly elevated above the rest of the scene. The magenta band appears to be the columns which have a similar number of CO2 ice and ice-free pixels, so the median value (and adjustment due to flattening) is actually controlled by the H2O ice pixels. Here's a quick comparison I put together showing the ICE summary product for the TER version of this scene in sensor space. The image on the left is with no flattening applied, and the image on the right is after flattening. It's a little easier to see how the amount of CO2 ice vs. ice-free pixels in each column controls the overall color in the flattened version. I recommend skipping the flattening step while processing this particular scene. This will make the data a little noisier, but will fix the issue you see here with significant banding in the summary products. Unfortunately, I am unable to help with the second anomaly you reported. A few other people in our group are taking a look into it, and will hopefully report back soon with what they discover. Best, John

Hi Tejay, I've spoken with the CRISM team about this issue, and they let me know that they updated the formulations of the BD1900_2 and BD1900R2 parameters in order to make the products less noisy. The preferred formulations these parameters for hyperspectral data are now: BD1900_2: just BD1930 with slopes anchored at 1850 and 2067, with kernels of 5 for all wavelengths BD1900R2: as listed in the SIS except with slopes anchored at 1815 and 2132, with kernels of 5 for the anchors and 1 for all other wavelengths I'll be working with the CRISM team to make sure the documentation gets updated to reflect this. As an additional note, many of the parameters have slightly different formulations for hyperspectral vs. multispectral data. In most cases, the main difference is kernel width (multispectral products always use a kernel width of 1, since there are fewer wavelengths available), but the following products all have other differences: RPEAK1, BDI1000VIS, BDI1000IR, VAR, BD1500_2, BD1900_2, BD1900R2, BDI2000, BD2100, BD2100_2, BD3400, BD3400_2. I'll be working with the CRISM team to make sure these differences are fully documented in the SIS. Best, John

Hi Tejay, For MIN2200 - yes, that currently uses a kernel width of 3 for R2210. That looks like a typo in the documentation (they have R2120 listed twice), so I'll pass it along to the team to get fixed. For BD1900R2 - I'll check with the CRISM team on what kernel widths were used to generate the SU product. The calculations that I can see suggest a kernel width of 5 for the two anchor points and a kernel width of 1 for all the others, but it looks to me like the kernel width of 3 you suggest does a slightly better job of reproducing the data in the SU product. John

Hi Tejay, I've confirmed your assessment that the BD1900_2 values reported are actually calculations for BD1930, instead. I've also tracked down the issue with BD1900R2 - in the SU file you referenced, the slopes for RC#### were calculated using R1815 and R2132, instead of R1850 and R2060. Your calculations for BD1900_2 and BD1900R2 are correct, so I would recommend you keep using those. I'll reach out to the CRISM team regarding these issues you identified in the parameter calculations so we can get them corrected. John

Hi Tejay, Thanks for bringing this to our attention! There's definitely something odd going on with those two parameters in the SU file you referenced, and I agree with your initial assessment that the BD1900_2 values reported look like they're reporting BD1930, instead. I'll look into this in more detail, and report back here once I figure out what's going on. John

R/Rc is the ratio of the actual reflectance spectrum to the continuum spectrum (basically a straight line connected over the absorption band). ENVI has a Continuum Removal tool (see https://www.harrisgeospatial.com/docs/ContinuumRemoval.html) which looks to me like it performs this calculation for you. If you start with the M3 reflectance images (files that end in "_rfl.img") and use the Continuum Removal tool, the result should be the ratio R/Rc for each band. Then you can use the Band Math tool to put together the sums needed to calculate integrated band depth. Note: I'm not all that familiar with M3 data processing, so you might want to confirm this is the right approach with someone from the M3 team before using this in any publications.

Hi Arpita, Just to confirm, you're looking at the formulas on page 4 of this paper, right? https://pubs.er.usgs.gov/publication/70034937 It looks like those are calculating the band depth (1 - R/Rc) at a number of adjacent bands, then adding them together to get the integrated band depth over a range of wavelengths; the variable 'n' is just used to indicate which bands are used in the calculation. So for the 1 micron integrated band depth, you'd calculate band depth at each of 789 nm, 809 nm, 829 nm, and so on, up to 1309 nm, and then add the results (with a similar calculation for 2 micron integrated band depth, just using different M3 bands in the sum). If you're using ENVI for your analysis, the Band Math tool should be able to help you calculate the band depth for each band that you're looking at, then sum up all of the results. John