Hi David,

Thanks for your interest. We do not have a worked example but it is relatively easy to get started.

If you want to run the algorithm on your own rasters (e.g. arbitrary SST images you provide), you should use the tools in MGET à Oceanographic Analysis à Find Fronts with Cayula-Cornillon Single Image Edge Detection à In ArcGIS Raster. This is a bit tricky because the algorithm was written to run on integer value, which were often provided in the earlier years of remote sensing (e.g. to save disk space and bandwidth), but modern products usually represent SST as floating point values of degrees C. Thus it is necessary to convert the floating point values to integers, either yourself or by supplying an _expression_ to the tool that tells it how you want the conversion to be done. I can help you with this, if you decide to take this route.

The simpler way to run the algorithm is to use one of the implementations of it that we have pre-customized to particular data products. For example, you could go to MGET à Data Products à NASA JPL PO.DAAC à GHRSST L4 SST and find a tool there specifically for detecting fronts in the GHRSST L4 products. The attached Find_Fronts_parameters.png is a screenshot of example parameters. In it, I left all parameters at their default values except these:

1.    GHRSST L4 product – I picked the popular MUR-JPL-L4-GLOB-v4.1 1km daily SST product. (Beware that this product does not somehow magically produce perfect cloud free SST at 1 km. There are major caveats to all SST products, including this one. I just picked it as an example. Other products may be better for your situation.)

2.    Front detection threshold – I set this to 0.5 deg C. Setting it higher finds fewer fronts, lower finds more fronts. Beware that most remote sensing data is only accurate to 0.3 or so; you should carefully read the documentation and papers associated with whatever data you use. Also, if you run the front-finding tool that works on generic images, you do not input the threshold in deg C. Read the documentation carefully for that tool.

3.    Output workspace – I set this to a directory to receive the images.

4.    Spatial extent – I set this to the Gulf Stream in the western North Atlantic, where many fronts occur.

5.    Start date, End date – I picked a range of dates last summer that had relatively clear skies in the area of interest, allowing the MUR product to show finely resolved values at 1 km SST, with relatively little smoothing. (The smoothing gets much stronger during cloudy times.)

By default, the MGET tool runs some “cleanup” steps (you can read about these in the tool documentation). Those are implemented in MATLAB code, and in order to run them you need to install the MATLAB Component Runtime (MCR) 7.7. You can get that free here. Please note that it is not sufficient (nor necessary) to have MATLAB itself installed. MGET cannot use your own copy of MATLAB; it must have the MCR (and it must be version 7.7 of the MCR).

The fronts tool produces rasters that show the fronts, but not the SST itself. It is helpful to have SST to view below the fronts, to assess how the tool is doing. I used the Create Rasters for GHRSST L4 SST tool to do that. The attached Create_Rasters_parameters.png shows that. As above, I left all parameters at their defaults except for a few. The third attachment shows a screenshot in ArcMap of the fronts overlaid on the SST for the day 2010-08-10, which seemed to be relatively clear, allowing fine details to be observed. Note that the MUR product shows fine detail in some areas of the image (e.g. along the Gulf Stream itself) but not in other areas (e.g. the Gulf of Maine, to the upper left). This relates to how the MUR product deals with clouds; you will have to read up on it to know more.

You can also see the front detector did not draw fronts in certain places, such as the warm areas near the bottom of the image. You can see an eddy at the center bottom that is only partially traced by a front. In these places, the SST did not exceed the threshold of 0.5 C that I picked. A lower value would probably yield a ring around that eddy, although fronts might show up in other places that were not desired. Depending on your objectives and the data you’re using, it can take a long time to tune Cayula-Cornillon algorithm and it is usually not possible to able to achieve perfect results in the end. For comparison, you can also try the Canny algorithm. I have found that this seems to work better in many situations. A caveat is that although the Canny algorithm is very, very well established in the computer vision field generally, it has relatively few applications to front detection compared to C-C.

Once you are confident that one or the other algorithm will work for you, you can invoke them from R. I no longer suggest the R COM route. My new suggestion is to try the rpython package, which hosts the Python interpreter in R directly. If you get to this point, I can show how to call MGET’s Python functions from R using this package.

Hope this helps,

Jason

From: [mailto:] On Behalf Of David March
Sent: Wednesday, February 22, 2017 10:34 AM
To:
Subject: [mget-help] front detection