Skip to Content.

mget-help - RE: [mget-help] 4km AVHRR SST from Pathfinder v5.2 and Cayula-Cornillon Fronts

Please Wait...

Subject: Marine Geospatial Ecology Tools (MGET) help

Text archives


From: Jason Roberts <>
To: Dori Dick <>
Cc: "" <>
Subject: RE: [mget-help] 4km AVHRR SST from Pathfinder v5.2 and Cayula-Cornillon Fronts
Date: Wed, 22 Oct 2014 22:07:26 +0000
Accept-language: en-US

Hi Dori,

 

Thanks for your interest in MGET. The reason you did not find a front detection tool customized for Pathfinder 5.2 is that, sadly, Pathfinder 5.2 is not suitable for front detection, at least for strong fronts such as the Gulf Stream. So we did not develop one.

 

The problem with Pathfinder in general is that its cloud masking algorithm emphasizes maximizing the accuracy of SST measurements over minimizing loss of pixels due to clouds. The way that this choice plays out is rather complicated:

 

Together with each SST image, Pathfinder provides a pixel quality image that say how good the SST pixels are, with values 0-7 where 7 is best and 0 is worst. They use a series of pass/fail tests in a flowchart to decide which value from 0 to 7 is assigned. Two of the tests are Uniformity Tests 1 and 2. Kilpatrick et al. (2001) provide this description of Uniformity Test 1:

 

    The brightness temperatures for channels 4 and 5 are examined for

    all pixels within a 3x3 pixel box centered on the pixel being

    classified. The difference between maximum and minimum brightness

    temperatures for each channel within this box must be < 0.7 deg C.

    This test seeks to identify contamination by small clouds and is

    based on the assumption that brightness temperatures should be

    relatively uniform at small scales under cloud-free conditions.

    Analysis of the PFMDB has shown that for channel uniformity

    thresholds below 0.7 degrees, no significant bias was detected in

    PFSST estimates and the rms of PFSST residuals was relatively

    uniform. However, pixels in areas of sharp frontal features on

    scales smaller than 12 km may be identified erroneously as suspect

    by this test.

 

Uniformity Test 2 is the same, except that the threshold is 1.2 deg C. So, in short, any pixel that has a gradient greater than 0.7 C will fail Uniformity test 1, or 1.2 C will fail Uniformity Test 2.

 

In the flowchart that decides the overall quality flag of 0 to 7, any pixel that fails Uniformity Test 2 is assigned quality 0. This means that in order to use Pathfinder for detection of fronts that are more than 1.2 C, you cannot use Pathfinder’s overall quality flag to mask the clouds. You have to mask the clouds in some other way. With the 5.0/5.1 tools, we were able to expose the individual pass/fail tests and allow you to select among them, to create your own custom combination of flags for masking. This will allow you to ignore the Uniformity Tests and try to use the other flags for masking. Sometimes that works ok, sometimes not. We also developed our own logic for using those flags in a scheme more sophisticated that just the Boolean combination of several flags. We implemented this as the “optimized” cloud masking algorithm in the 5.0/5.1 front detection tool. It is enabled by default, although since that time we have found some situations in which it does not work—it fails to mask all of the clouds. So use it with caution.

 

Now to Pathfinder 5.2. The unfortunate thing is that 1) they don’t expose the pass/fail tests, so we can’t use them. And 2) they mask, at NOAA, any pixels that have an overall quality level of 0. This means that any pixel that fails Uniformity Test 2 is masked by NOAA, with no way to get it back. This is ultimately what makes 5.2 unsuitable for front detection.

 

For an example, see the two images below my signature. The first one is an image of the Gulf Stream on 2005-04-20, one of the most cloud-free images of the Gulf Stream that I know of. This is a 5.0 image with no pixels masked—it is what you get if you set minimum overall quality flag to 0 in the MGET tool. You can see the beautiful image of the Gulf Stream with its eddies, and some obvious clouds.

 

The second image is the Pathfinder 5.2 image with the minimum overall quality flag also set to 0 in the MGET tool. MGET is not masking anything. Sadly, NOAA already masked all pixels that have quality 0. You can see the overall data loss, and notice many edges of the Gulf Stream and its eddies are masked. This is due to the failed Uniformity Test 2. You can reproduce the same effect with the MGET 5.0/5.1 tool by increasing the minimum overall quality flag from 0 to 1.

 

My recommendation is to try the 5.0/5.1 tool with the optimized cloud masking algorithm. If that works ok for you, then go with it. If not, try MODIS Aqua L3 SST instead. Or try one of the GHRSST L4 products available from PO.DAAC, which are cloud free. My current recommendation is the CMC 2.0 SST, which is 9 km but seems to represent fronts reasonably well. Note that if you try the 1 km OUROCEAN or MUR products, they take a VERY LONG time to download from NASA, due to a problem on their server. And OUROCEAN may show false fronts due to how it combines SST images. I do not currently recommend the 1 km GHRSST L4 products for front detection, due to these difficulties.

 

I hope that helps…

 

Jason

 

 

 

From: Dori Dick [mailto:]
Sent: Wednesday, October 22, 2014 4:03 PM
To:
Subject: [mget-help] 4km AVHRR SST from Pathfinder v5.2 and Cayula-Cornillon Fronts

 

Hello,

I am using MGET version 0.8a56 and would like to create thermal fronts using the AVHRR Pathfinder v5.2 data.  Unlike the v5.0 and 5.1 SST, there appears to be no option to create Cayula-Cornillion fronts directly within the NOAA NODC --> 4km AVHRR Pathfinder v5.2 SST tools.  However, I do see another option to "Find fronts with Cayula-Cornillon SIED" within the Oceanographic Analysis Tools.  I am assuming I could use this set of tools with the v 5.2 data to find thermal fronts but have been unable to determine if the scale factor, offset and scaling equation for integer conversion are the same or different for AVHRR v5.0/5.1 and v5.2.  I suspect the values would be different given that v5.2 was derived using a different data prep system.

I have checked the NOAA NODC website and have only been able to find values for Pathfinder v5 (here: http://www.nodc.noaa.gov/SatelliteData/pathfinder4km/userguide.html) which match to those you list in the help section for the v5.0/5.1 tools.  Do you have any idea what the scale factor, offset and scaling equation for integer conversion would be for v 5.2 or can you direct me to a website with this information?

Thanks in advance for your assistance,

Dori Dick

~~~~~~~~~~

 

Archives powered by MHonArc.
Top of Page