SeaDAS 5.0.x provides support for the MUMM NIR correction.
I have been using the MUMM algorithm for some time.
It consists of 2 steps:
1) Obtain the Rayleigh corrected radiances in the NIR bands and determine mumm_epsilon.
2) Do the atmospheric correction using the mumm_epsilon value determined in step 1.

Can someone explain to me how to get the Rayleigh corrected radiances using SeaDAS 5.0.x ?

MUMM is not "officially" supported in msl12, because I implemented it based on information provided to me by K. Ruddick on a dinner napkin.  I was waiting to hear some feedback regarding the implementation before it is made public, and before I recommend that it be incorporated into the SeaDAS GUI.  However, if you wish to try it, I suspect you already discovered that msl12 has some new inputs.

% msl12 | grep mumm
   mumm_alpha=water-leaving reflectance ratio for MUMM
   mumm_gamma=two-way Rayleigh-aerosol transmittance ratio for MUMM
   mumm_epsilon=aerosol reflectance ratio for MUMM

Default values are:
  input->mumm_alpha = 1.72;
  input->mumm_gamma = 1.00;
  input->mumm_epsilon = 1.00;

You need to set aer_opt = -10 for msl12 to utilize the mumm parameters.  As for the determination of mumm_epsilon, what you require is beyond Rayleigh-corrected radiances.  The input to MUMM epsilon is a form of water + aerosol reflectance.  The observed reflectance is corrected for Rayleigh, whitecaps, glint, and diffuse and gaseous transmittance, as well as polarization effects in the case of MODIS.  There is a new MUMM-specific reflectance product called rhom_xxx, e.g.: rhom_765, rhom_865, that I believe is what you need. You can output this with msl12.

You can do all this with the msl12 binary provided in the latest SeaDAS, but the options do not appear in the GUI and so you must use the commandline processing.

-- bryan

Dear Bryan

Thanks for implementing the MUMM option.
I will test it asap and give feedback.

Regards, Gerard

Dear Bryan

Last week I payed a visit to Kevin at MUMM in Brussels.
At the moment Bouchra Nechad from MUMM is checking the correct implementation of the code.
It turns out that there is a (small) mistake in get_l2prod_index.c.
The program outputs rhos instead of rhom (see line 2004).
I recompiled the "corrected" code and reprocessing of old images gave similar results.
Surprisingly the rhom values can be "NaN" or "Inf" in the new code.
I reported this to Bouchra.
Hope you can correct the above typo error in a coming update of SeaDAS.

Regards, Gerard

Good catch.  Thanks.  I'll see if I can verify and fix the NaN problem.

-- bryan

Gerard, Bouchra,

In my tests, the Inf and NaN were occurring over land pixels.  The underlying problem is that the polarization correction (which is a divisor in the rhom computation) is initialized to zero and only computed (or reset to 1.0) over water.  Obviously, MUMM users don't need reflectance over land, and I can easily fix the code to set land pixels to a number  (-1, -1000?).  However, it might make more sense to do the same for any pixels masked during L2 processing (e.g., due to clouds).  I'd like some feedback here, as I don't know what MUMM users want, given that it is possible for highly turbid waters to get erroneously flagged as cloud with our simple threshold test. i.e.:

  if rhos[865)] > 0.027 then CLOUD

Can I assume that MUMM users will be able to identify/ignore contaminated rhom retrievals in post processing?  If so, I will just set rhom=-1000 for all land pixels, and compute rhom over all ocean pixels, regardless of potential cloud/glint/straylight contamination.

-- bryan

Dear Bryan

In the old MUMM code rhom (called Rc in version 4.8) used to be initialized as the other L2 data (Rrs, nLw, etc) in the section "Initialize output values..." within atmocor2.c: Rc[ib]=badval.
In the new version, rhom is computed inside mumm.c (get_rho_mumm procedure) and
rhom is not initialized.
Is it possible to initialize rhom as the other L2 data?

The problem with highly turbid waters erroneously being flagged as clouds,
is well known to (most) MUMM users as it is also mentioned on the MUMM
ocean color website.
To avoid flagging of turbid areas the cloud threshold should be raised (>0.027).

Gerard

O.K., I will make it behave as it was before.  I will set rhom to zero and only computed it where atmospheric correction is computed.

Just FYI: the old implementation (i just downloaded it) added the Rc field to the L2 structure, so it was actually initialized when the structure was allocated (alloc_l2.c).  The 2nd initialization in atmocor2.c was for good measure.  In this case, adding a field to the L2 structure is unneccessary and it adds additional code changes and memory requirements.  The mumm reflectance is trivially computed from existing terms, and it is only used for one purpose, so it need not be saved internally.  My intent was also to  better isolate the mumm modifications to simplify maintenance.

thanks for the info.
Bryan

Bryan, Gerard,

First of all, thanks for programming the lines for our code, Bryan. We've been trying to keep this maintained for a number of years now via our own web site, but we just can't keep up with all the updates of SeaDAS. It will save us a lot of time now that the code is in the standard version as an option even if it's not yet officially supported.

Thanks also, Gerard, for helping to spot the problem of rhom (not rhos) output, which is now apparently fixed.

Bouchra has gone through the code carefully here and we are pleased to confirm that everything works OK. We had some internal discussions about the band-averaged vs band-centered approach and concluded that you are best placed, Bryan, to decide which is best.

Two points to add to the discussion:

1. The discussion about cloud-flagging is obviously relevant to turbid waters, because as you say the simple threshold test on rhos[865] will flag many turbid waters as clouds. Like most turbid water users, we just increase the threshold to avoid this cloud-flagging. We'd then hopefully catch clouds later in the L2 processing as high Tau or failure pixels. However, I'm a bit surprised that the rhos[865] threshold test is still being used. Are there no better cloud detection algorithms around? At least to distinguish between turbid waters and clouds should be quite easy because they have very different spectral reflectance, clouds being fairly white and turbid waters being very obviously non-white, especially in the near infrared. Menghua once presented (Ocean Optics 2000?) a red/blue test which should distinguish nicely between most cloud-free atmospheres (with Rayleigh scattering giving much higher blue radiances) and clouds. Are there difficulties designing better general pixel-by-pixel cloud detection algorithms than the rhos[865] test or is there just no-one else that asking for something better?

2. For information, we published recently a synthesis of seaborne near infrared water-leaving reflectance measurements which can be found at:
http://aslo.org/lo/toc/vol_51/issue_2/1167.pdf
with two web appendices describing the measurement protocol and uncertainty analysis at:
http://aslo.org/lo/toc/vol_51/issue_2/1167a1.pdf
http://aslo.org/lo/toc/vol_51/issue_2/1167a2.pdf

This is relevant to the MUMM atmospheric correction previously documented in our 2000 Applied Optics paper (http://www.mumm.ac.be/BELCOLOUR/Publications/Ruddick%201.pdf), because it gives the near infrared water-leaving reflectance ratio that should be used for MODIS-AQUA bands 746nm and 866nm: mumm_alpha=1.945 (see Table 3 of abovementioned paper). In this paper, we couldn't measure accurately enough the corresponding ratio for SeaWiFS 765nm:865nm because the atmospheric oxygen absorption at 762nm makes it very difficult to measure the water-leaving reflectance for the SeaWiFS band. We still use mumm_alpha=1.72 for SeaWiFS.

Thanks again for the great work keeping SeaDAS maintained and improved! When I started out in atmospheric correction I learnt so much from just reading the SeaDAS software. Moreover, the open source policy really ensures that the science progresses rapidly - I see that the SWIR correction is now programmed so I'm interested to see how that performs in general. It could be very effective for turbid waters even though the MODIS SWIR bands were not really designed for that. Now I'm also curious about exactly how they do that atmospheric correction for MERIS so it's a shame the MERIS processor is not so open. Is it difficult to extend SeaDAS to perform an atmospheric correction for MERIS?

Kevin

Kevin,

Regarding the band-pass issue: we have full-band water+aerosol radiance, which is being normalized by instantaneous, full-band solar irradiance.  This should be fine.  Besides, there is currently no mechanism to correct from full-band to nominal center-band, since that would require hyper-spectral knowledge of the combined aerosol+water reflectance.  I imagine it could be done in some iterative fashion, but I don't think the effort would be worth the benefit.  The correction process would likely be more uncertain then the effect.

On the cloud screening:  First, it's a question of priorities. We hear few complaints, so improved cloud detection is very low on the to-do list (at least for ocean color).   Given the limited availability of SeaWiFS 1km data, I would think that future coastal remote sensing interest will be focused on MODIS or other sensors.  With the recent modifications of MODIS processing to allow use of the SWIR, we include the switch to SWIR-based cloud detection (i.e., rhos(2130) threshold).  We also have the (unadvertised) ability to use the MODIS cloudmask product as input for screening.  We need to evaluate these alternatives.

Regarding mumm_alpha: we can easily make the default mumm_alpha=1.945 for the MODIS sensors and mumm_alpha=1.72 for SeaWiFS.

Regarding MERIS: again it's a question of priorities.  In this case, at the agency level.  It's also a question of data access. It would be relatively trivial to incorporate MERIS processing into msl12, to apply seawifs-like atmospheric correction.  All we really need is access to instrument-calibrated Level-1B products, the instrument spectral response functions, and a few weeks to generate the atmospheric tables and i/o code.    But, we'd be giving the community a mechanism to generate products that may be inconsistent with the standard MERIS products.  That might not be appreciated.  To incorporate standard MERIS processing into msl12 or SeaDAS would require access to the source code, with permission to distribute, and probably much more effort on our end to implement.  Anyway, my guess is that we will eventually add some kind of support for MERIS processing in SeaDAS, or at least MERIS display, but the OBPG has not yet been given the directive from above to do so. That's my unofficial take on it.

-- bryan

Hello Bryan,

How to implement this rhos(2130) threshold in the msl12 Unix binary execution?  Does it need to combine with other arguments for a better coastal turbid water Aqua processing? e.g.:
aer_opt=-10 (to apply MUMM correction)
mumm_alpha=1.945 (for Aqua sensors)
aer_wave_short=1240
aer_wave_long=2130
any others ?

BTW, is this SWIR-based cloud detection scheme the same approach described in Wang & Shi (2006, IEEE Trans. Geo. Rem. Sen, vol 44, no. 11, p3196-3205)?  If not, will your team consider to incorporate this approach into SeaDAS as an option of cloud masking in SWIR high resolution processing?  Seems this new approach provides much better cloud detection results even in very turbid waters (e.g. Wang et al., 2007. GRL, vol 34, L06611, doi:10.1029/2006GL028599).

Thanks,
-Haili

In general, I would not combine SWIR-based atmospheric correction and MUMM.  There is no need. 

Either:
aer_opt=-1
aer_wave_short=1240
aer_wave_long=2130
gas_opt=11

Or:
aer_opt=-10 (to apply MUMM correction)
mumm_alpha=1.945 (for Aqua sensors)

If the L1B data includes SWIR bands, and the resolution is not set to -1, then the 2130 band will be used for the cloud test, with a threshold of 0.018.  This is consistent in spirit with the Wang & Shi paper. The switch is automatic in msl12.

-- bryan

Hi

mumm_alpha = 1.945 for all MODIS sensors? I'm using Terra.

The 5.1 version has all of the "problems" mentioned above fixed?

Best regards.

Akli

Yes, mumm_alpha = 1.945  is the default for all MODIS sensors.  I can't say I've ever tested it for Terra.  There are much bigger problems with MODIS-Terra than a little non-zero NIR water-leaving reflectance.

-- bryan

I found that for Terra it is 1.984 in this post http://www.mumm.ac.be/OceanColour/Products/Software/use.php.
I am wondering if it is good to tune both the mumm_gamma and mumm_epsilon for each image? is the mumm_alpha good to set to 1.945 for the aqua sensor so we don't need to tune it? Thank you.

The 1.945 is what the MUMM group provided as a reasonable default for MODIS (any MODIS, since it's a question of band location).  The numbers on their website may be slightly outdated.  The intent of the MUMM is that you tune every scene (or at least tune for typical conditions of your region of interest).  The defaults are only provided as a starting point. The Rc7 and Rc8 in the MUMM documentation is what we refer to in SeaDAS as rhom_748 and rhom_869 (for MODIS), so you can output the required products and follow the procedure outlined. I don't have any experience with this approach, so you should contact the MUMM group for further advice.  Perhaps one of them will respond here (hint, hint).

-- bryan

Hi

I've used the MUMM algorithm to correct Terra data and generate chl-a values in an Case 2 estuary. I compared the chl-a outputs of several atm correction procedures and MUMM apparently retrieved better chl-a values than the standard procedure, for example.

I did the same thing with Aqua data and I have almost no chl-a values. I compared it (only) with the standard correction output chl-a values, and the latter outputs several valid pixels although I don't know the accuracy.

Any idea why this is happening?
Since no one replyed to this post, will I have to contact the MUMM group to understand the reason behing this?

Regards,

Akli