Joaquim Luis wrote:
After that I wrote a MEX version of gdaltransform to be able to
reproject points using GCPs.
This MEX works but it revealed serious problems. At least under Matlab.
Matlab requires not only LOTS of memory but also that the available
memory is continuous.
For example, if
Hi,
I managed to solve my problem with the GCPs in MEM driver (and sorry if I
bothered some with
that thread), which turned up to be due to a bad initialization of the dataset
geotransform.
After that I wrote a MEX version of gdaltransform to be able to reproject
points using GCPs.
This MEX
Frank Warmerdam wrote:
Joaquim Luis wrote:
So one question is, why warping with GCPs takes such large amount of
memory (apparently a chunk
of 500 Mb was not enough to process 5000 GCPs)?
Joaquim,
Is the memory fragmentation really related to the use of many GCPs? Does
the same problem
Joaquim Luis wrote:
Frank,
Maybe I was not clear enough, but the memory segmentation has nothing to do
with the GCP warping. It results from loading the gdal.dll
For example, on a fresh start if I call (one other MEX for reading)
gdalread
without arguments, it prints the usage on screen.
Joaquim,
OK. Well, generally speaking GDAL should allocate relatively little
memory just on loading the DLL (and perhaps calling GDALAllRegister()).
So I don't know why you are seeing the problem you see.
Frank,
It's ok. I was not expecting an easy answer but I think this issue worth
Does this aspect really have anything to do with the number of GCPs?
Are you using the GDAL warp algorithm?
Oh yes, with 2500 GCPs I can do the warping. And yes I'm using the
GDAL warp algorithm (the mex is more or less a copy of gdaltransform)
Sorry for being so dumb. The GCP warping
