The *next* release of SeaDAS will have the area_weighting option in l2bin. Don thought we'd already put it out.
There is, however, an area weighting available in l3mapgen, which is almost as good :grin:
interp=areafor the l3mapgen calls. You can squeeze a little more out by also adding
I have a question on the scaling, what is the math that is used for the linear and the log scaling?
For example, is it based on the default data_min, data_max for a given product? such that if multiple shots are processed they all get the same scaling?
If so, then I'm assuming that the math for linear scaling is something like this to scale it into 0-255 image palette:
pixel = (value - data_min)/(data_max - data_min)*(255 - 0) + 0
So then is log scaling done like:
pixel = (log(value) - log(data_min))/(log(data_max) - log(data_min))*(255 - 0) + 0
For the Kd_490 band I think data_min=0.01 and data_max=6.4 and the units are m**-1, so using the blue-red palette larger numbers are more red, which is what I'm getting. I can't quite get my head around how to interpret/visualize inverse meters (m**-1). I get particle reflectance, so more particles more reflected, clear water nothing reflected. Is that the right way to think about this?
Kd_490 is a diffuse attenuation, the larger the value the more light is attenuated (per meter) with depth (along the path of light). So, it's not that there are more particles (and thus there is more reflectance) it's that there is more stuff attenuating light along the path. This means less light penetration. Since attenuation includes contribution from both scattering and absorption, it could be that increased Kd is due to increased particles concentration, which would result in increased backscattering, and thus increased reflectance. But it could also be increased absorption, so less backscattering and less reflectance.
That said, the algorithm currently used employs a band ratio of remote sensing reflectance :grin:
l3mapgen interp=area 'projection=+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs' threshold=0.5 ofile=OCL.tif north=42.42578 south=23.89974 west=-90.39094 east=-69.06195 ifile=MOD00.P2020058.1835_1.PDS.chl.L3b.nc oformat=tiff fudge=3.0 product=chlor_a apply_pal=0 quiet=0 resolution=qkm scale_type=linear
I seem to get the same output regardless of setting scale_type= linear or log.
This seems makes sense as you are scaling a potentially larger range of values into the fixed 255 bucket palette. where as the gray scale is outputting float32 value so there is not need to scale that.
Sorry for all the questions, but this has been extremely useful. Thank you very much.
Correct, scaling is only applied when a color palette is applied. As you noticed, when grayscale is output, the TIFF is written as a float, so no scaling is applied.
The l3mapgen help page shows and example of using: rhos_670,rhos_555,rhos_412
above says to use: rhos_469,rhos_555,rhos_645 (this generates a buddy brown that overlays the chlor_a, and sst data, but no clouds,water or land)
I assume the numbers are frequencies so lower is more red and higher is more blue.
what are the best to get a reasonable true color image?
What should I use for flags if I want to see clouds, land, water, etc, basically just ignore bad/questionable pixels.
Do I need the apply_pal=1, since the output image is not paletted?
What value do nodata pixels get set to?
I'm currently using:
l2bin prodtype=regional ofile=$name.sst.L3b.nc infile=$name.sst.L2.nc resolution=Q average=area l3bprod=sst,rhos_469,rhos_555,rhos_645
l3mapgen interp=area 'projection=$proj' threshold=0.5 ofile=$name.L2_TC.tif north=$north south=$south west=$west east=$east ifile=$name.sst.L3b.nc oformat=tiff fudge=3.0 use_rgb=1 product_rgb=rhos_469,rhos_555,rhos_645 apply_pal=1 quiet=0 resolution=qkm
I presume, that I'll need to run l2bin once for sst and again for the rhos_vvv set using different flags which I'm ok with. from the l2bin Help page:
flaguse (string) (default=ATMFAIL,LAND,HILT,HISATZEN,STRAYLIGHT,CLDICE,COCCOLITH,LOWLW,CHLFAIL,CHLWARN,NAVWARN,ABSAER,MAXAERITER,ATMWARN,HISOLZEN,NAVFAIL,FILTER) = flags masked [see /SENSOR/l2bin_defaults.par]
and ./share/modis/l2bin_defaults.par has
The numbers refer to the wavelength of the band, related to but not frequency. So, smaller (shorter) wavelengths tend toward blue, longer red.
469nm is blue, 645nm is red.
SeaDAS comes with some default files for l2bin and l3mapgen that make it easy to generate a true color image. Simply use the suite SFREFL, e.g.
l2bin suite=SFREFL ifile=<input L2> ofile=<output L3b>
l3mapgen suite=SFREFL ifile=<input L3b> ofile=<output mapped TC>
The suite just defines parameter so you don't have to remember them all:
$ cat l2bin_defaults_SFREFL.par
$ cat l3mapgen_defaults_SFREFL.par
As you can see, your calls are pretty close. So yes, what you were missing was the flaguse parameter. The default flaguse parameter excludes a lot of things...like land and clouds...so you get not so true color images :wink: