Help with Aqua/Terra MODIS RGB 250 m

[jvaldezch]

Hi, I have been using l1mapgen to produce some Aqua/Terra MODIS RGB from L1b level with 250 m resolution but I'm getting some wierd results.

Red arrows marking wierd artifacts


This is the command used:

l1mapgen ifile=A2018227192500.L1B_LAC geofile=A2018227192500.GEO resolution=250 ofile=A2018227192500_rgb.tif east=-84.3 west=-97.42 north=19.51 south=16.08 width=6000 oformat=tiff

[OB SeaDAS - dshea]

Looks like you have some fast moving clouds in that scene.  I only see the artifacts in the clouds on the scan boundaries. Since the time between MODIS scans is 1.477 seconds, I think you are seeing adjacent pixels from different scans as the cloud moves.

don

[OB WebDev - norman]

Hi,

The l1mapgen software is based on a program I wrote in 1997 called swtcpcbox.
That software estimated the ___location of the four corners of each pixel in the projected
Cartesian space and then used a technique from early X-server code called scan-conversion
to fill in the projected pixels covered by the original source pixel.  This worked well enough
for sensors like SeaWiFS that had (essentially) one detector per scan line.

The MODIS 250-meter bands have 40 detectors per scan line, however,  and the edge
detectors from adjacent scan lines do not view adjacent patches of Earth's surface when
viewing in an off-nadir direction.  This messes up the estimated pixel-corner locations a bit
for the two outside detectors in the focal plane.  I used to get similar artifacts to what you
are seeing when I started working with MODIS data.

My current approach to making imagery from the MODIS data is to use l2gen to
generate rhos (i.e. surface reflectance) products.  I then project each pixel using its
center coordinate (stored in the l2gen output file) and use a nearest-neighbor algorithm
to fill in the output Cartesian grid instead of using the older, less-bowtie-compatible
scan-conversion method of swtcpcbox (and presumably, l1mapgen).

If you want a more detailed description of what I do you can find an example here.
https://oceancolor.gsfc.nasa.gov/forum/oceancolor/topic_show.pl?pid=32059

Regards,
Norman

P.S.  I think a replacement for l1mapgen is in the works.

[OB.DAACx - SeanBailey]

> P.S.  I think a replacement for l1mapgen is in the works.

Well, there is a replacement - just haven't had time to fully test it, so I hesitate to promote it just yet...
It's a python script - l1mapgen.py - and is in the current release, and it does work...at least for me :wink:

...and it works by generating rhos using l2gen, binning that using l2bin and mapping using l3mapgen.

Give it a try and let me know how it goes :grin:

Sean

[jvaldezch]

Thanks Norman.

I'm following your steps as shown on post but I'm stuck at convert. I'm getting the following error:

convert: negative or zero image size `rhos_645_q.16bit.log.pgm' @ error/pnm.c/ReadPNMImage/434.
convert: negative or zero image size `rhos_555_q.16bit.log.pgm' @ error/pnm.c/ReadPNMImage/434.
convert: negative or zero image size `rhos_469_q.16bit.log.pgm' @ error/pnm.c/ReadPNMImage/434.
convert: no images defined `A2018227192500.rhos_645_555_469.log.tif' @ error/convert.c/ConvertImageCommand/3258.

All .pgm files are present with an average size of 175 MB. Not sure if it's related with my ImageMagick version (6.9.10-10 Q16 x86_64).

[OB WebDev - norman]

Are you able to display the input PGM files?  For example, does

display rhos_555_q.16bit.log.pgm

let you view the image?

(I am using ImageMagick version 6.8.9-9 Q16 x86_64 .)

Norman

P.S. What does

identify rhos_555_q.16bit.log.pgm

show?

[jvaldezch]

Both commands are showing the same error:

~ # display rhos_555_q.16bit.log.pgm
display: negative or zero image size `rhos_555_q.16bit.log.pgm' @ error/pnm.c/ReadPNMImage/434.
~ # identify rhos_555_q.16bit.log.pgm
identify: negative or zero image size `rhos_555_q.16bit.log.pgm' @ error/pnm.c/ReadPNMImage/434.

[OB WebDev - norman]

What do these commands show?

ls -l rhos_555_q.16bit.log.pgm
head -1 rhos_555_q.16bit.log.pgm

[jvaldezch]

Norman, here is the output:

~ # ls -l rhos_645_q.16bit.log.pgm
-rw-r--r-- 1 jvaldez jvaldez 154730541 Sep 24 16:37 rhos_645_q.16bit.log.pgm
~ # head -1 rhos_645_q.16bit.log.pgm
P5\n8862 8730\n65535

[jvaldezch]

Hi Norman,

I found the issue. I have to change this line:

echo "P5\n7732 7733\n65535"|cat - nak.dat>$i.16bit.log.pgm

Into this:

echo $'P5\n7732 7733\n65535'|cat - nak.dat>$i.16bit.log.pgm

Now I got some black images but I think this is due coordinates.