| Re: ENVI_CONVERT_FILE_MAP_PROJECTION processing times [message #77490 is a reply to message #77477] |
Sat, 03 September 2011 05:35   |
devin.white
Messages: 50
Registered: March 2007
|
Member |
|
|
The reprojection routines used by interactive ENVI are indeed
different from (and superior to) those you can access via the API.
Especially for the Triangulation and Rigorous options. The
interactive version handles those cases much more efficiently. You'll
see the biggest difference when working with large images. The API
does certain preprocessing steps in memory (and in a different way)
than interactive ENVI and, as a result, you can run into memory
allocation problems for the same image that processed just fine in
interactive ENVI.
You'll want to avoid the Layer Stacking option, as that tends to use a
lowest common denominator approach to reprojection. Sure, it's fast,
but you pay a heavy price for that speed. It's better to get your
layers into the same projection and GSD (pixel size) first, then layer
stack.
The main issue I see with your code is the DIMS keyword usage and your
lack of the GRID keyword. Your call should look like this:
ENVI_CONVERT_FILE_MAP_PROJECTION, fid=gcov_fid, $
pos=pos, dims=dims, o_proj=srtm_proj, $
o_pixel_size=srtm_pix_size, $
out_name=out_name, warp_method=2, $
resampling=2, background=0, $
grid=[50,50]
You can't rely on the API to know that it only needs the first five
elements of whatever array you pass it. Some routines do check to
make sure the DIMS array has only five elements. The next time you
run interactive reprojection with Triangulation, note the number of
grid points it uses in X and Y and supply those to your call. I
*think* the interactive defaults are [50,50], but I don't recall what
the API defaults are. If they are higher than that, it would go a
long way towards explaining the increased processing time (denser grid
= longer processing time). FYI: WARP_METHOD=3 will always give you
the best results, but it is definitely the slowest option.
On Sep 2, 6:09 pm, David Fanning <n...@dfanning.com> wrote:
> Martin Landsfeld writes:
>> I am remapping some GeoCover imagery to conform to our SRTM data. The
>> GeoCover is in the UTM projection at 28.5 meters and the SRTM is in a
>> Geographic projection at 0.0008333 degree resolution. I can do the
>> conversion interactively in ENVI and it takes about 67 seconds. The
>> files are large with:
>
>> SRTM at 7208 x 9608 pixels
>> GeoCover at 26857x19517 pixels
>
>> I would like to run the conversions in IDL using the batch ENVI
>> function ENVI_CONVERT_FILE_MAP_PROJECTION but when I do, it takes
>> nearly 2 hours to process the same files on the same machine, a
>> Windows 2008 Server with 4, 2.2GHz. Quad-Core processors and 32GB RAM.
>
> I seriously doubt you are doing anything wrong. But, it
> has been my experience that ENVI does not use its own
> API. So, the way they do things internally, and the
> way they tell you to do them programmatically are
> really two different things. It wouldn't surprise me
> to find this is one of those cases.
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
