[gdal-dev] Re: VRT Derived Bands from Python?

[Knut-Frode Dagestad]

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
>