Hi Even and Antonio,
Thank you Even for explaining how to make the impossible possible!
I will explore this option.
The suggestion of Antonio to include a default set of PixelFunctions is
an excellent idea, as it lowers the threshold for newcomers, like me.
The proposed standard functions (#3367) should also serve many basic
needs, and in fact, most of mine.
On the other hand, I do not see any apparent limitation to how
sophisticated the PixelFunctions can be. I am not sure if it is a good
idea, but I consider the option to put in relatively complex algorithms
with loops, iterations and inversions. I.e. things that are better done
in C than in Python.
Best regards from Knut-Frode
On 11/05/2011 21:05, Antonio Valentino wrote:
Hi Even, hi Knut-Frode,
Il 11/05/2011 20:08, Even Rouault ha scritto:
Le mercredi 11 mai 2011 11:53:55, Knut-Frode Dagestad a écrit :
Hi,
Derived Bands of the VRT format seems like a very powerful resource.
From the tutorial (http://www.gdal.org/gdal_vrttut.html) it is clear
that the Pixel Functions themselves have to be written in C, which is
probably anyway best for performance.
I also get the impression that the corresponding VRT files with Derived
Bands can only be used by applications written in C/C++, since the Pixel
Functions are only available inside the scope of such an application
program:
http://gis.stackexchange.com/questions/2940/gdal-pixel-functions-question
Does this mean that Pixel Functions can not be used by command line
utilities (e.g. gdalwarp and gdal_translate) or from Python?
The quick answer is : you can't use VRTDerivedBand from command line
utilities or Python.
The long answer is : but of course, as often in situations where you can't,
you can... Provided you have a C compiler handy, the workaround here is to
benefit from the GDAL plugin mechanism for other purposes than writing a GDAL
driver.
Create a gdalmypixelfunction.c whose content is :
#include "gdal.h"
CPLErr MyFunction(void **papoSources, int nSources, void *pData,
int nXSize, int nYSize,
GDALDataType eSrcType, GDALDataType eBufType,
int nPixelSpace, int nLineSpace)
{
/* implementation to write here */
}
void GDALRegisterMe() /* this is the entry point. don't change this name */
{
GDALAddDerivedBandPixelFunc("MyFunction", MyFunction);
}
Compile it as a shared library, called gdal_XXXXXXXX.so (or .dll on
windows), define GDAL_DRIVER_PATH to point to the directory of the shared
library, et voilà ! The library will be loaded at runtime when the utilities
or the python bindings call the GDALRegisterAll() method and the pixel
function will be available to the VRT driver.
This is exactly the solution I'm currently using and I con confirm that
it works perfectly both on linux and windows.
I wrote a little plugin to register pixel functions attached to #3367
[1] (together with other more specific for my application domain) and
now both command line tools and python scripts can use pixel functions.
The only limitation is that there is no way, as far as I know, to write
a VRT file with a VRTDerivedRasterBand using the GDAL Python API.
While I can set the Band subClass at band creation time as follows:
ds.AddBand(gdal.GDT_Float32, ['subClass=VRTDerivedRasterBand'])
I was not able to find a way to set the PixelFunctionType and the
SourceTransferType parameters using the GDAL Python API.
As a workaround I write the VRT to disk and then I perform direct XML
manipulations via xml.etree (from the python standard lib).
Do I miss something?
It would be very nice to be able to set PixelFunctionType and
SourceTransferType asadditional creation options.
[1] http://trac.osgeo.org/gdal/ticket/3367
Best regards
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
