#3925 closed enhancement (fixed)
Allow addition of pixel functions to a band by name during band addition
Reported by: | klaricmn | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.9.0 |
Component: | default | Version: | svn-trunk |
Severity: | normal | Keywords: | vrt |
Cc: | bclaywell, antonio |
Description
The attached patch allows a pixel function to be added to a band by name (not function pointer) during programmatic creation of a VRT file.
See the following example:
#include <gdal_priv.h> #include <gdal_vrt.h> int main() { GDALAllRegister(); GDALDataset* old_dataset = static_cast<GDALDataset*>(GDALOpenShared("test.tif", GA_ReadOnly)); int width = old_dataset->GetRasterXSize(); int height = old_dataset->GetRasterYSize(); GDALRasterBand* old_band = old_dataset->GetRasterBand(1); GDALDriver* vrt_driver = static_cast<GDALDriver*>(GDALGetDriverByName("VRT")); GDALDataset* vrt_dataset = vrt_driver->Create("test.vrt", width, height, 0, GDT_Byte, NULL); char** options = NULL; options = CSLAddNameValue(options, "subclass", "VRTDerivedRasterBand"); options = CSLAddNameValue(options, "PixelFunctionType", "NameOfSomePixelFunction"); /* NOTE: The above line is what's allow by this patch */ vrt_dataset->AddBand(GDT_Byte, options); GDALRasterBand* new_band = vrt_dataset->GetRasterBand(vrt_dataset->GetRasterCount()); VRTAddSimpleSource(static_cast<VRTSourcedRasterBandH>(new_band), band, 0, 0, width, height, 0, 0, width, height, "near", VRT_NODATA_UNSET); GDALClose(vrt_dataset); GDALClose(rgb_dataset); return 0; }
Attachments (2)
Change History (14)
by , 13 years ago
Attachment: | vrt_pixelfunc.patch added |
---|
follow-up: 2 comment:1 by , 13 years ago
comment:2 by , 13 years ago
Replying to rouault:
I'm not sure of the interest of the patch.
Why not just doing :
...
VRTDerivedRasterBand* vrtderivedband = (VRTDerivedRasterBand*)band; vrtderivedband->SetPixelFunctionName("NameOfSomePixelFunction");
I thought the VRTDerivedRasterBand interface was unavailable outside the VRT driver itself, judging from gdal_vrt.h. Is it actually declared somewhere else that client code can use?
follow-up: 4 comment:3 by , 13 years ago
It is declared in vrtdataset.h. gdal_vrt.h is supposed to be the "public" C API of the VRT driver, but as you're using the GDAL CPP API, you can as well use vrtdataset.h
comment:4 by , 13 years ago
Replying to rouault:
It is declared in vrtdataset.h. gdal_vrt.h is supposed to be the "public" C API of the VRT driver, but as you're using the GDAL CPP API, you can as well use vrtdataset.h
Oops. I embarrassingly didn't know vrtdataset.h existed, so in that respect we probably don't need this patch :) But doesn't that still mean that users of the C API have no way to add a derived band in this way?
follow-ups: 8 10 comment:5 by , 13 years ago
Yes, users of C API cannot add derived band. But they could neither register the pixel function, so you definitely need C++ to use those advanced features of the VRT driver. I think we are not too keen on extending more the VRT C API, as it can be difficult to guarantee its stability when the VRT driver evolves.
comment:6 by , 13 years ago
Cc: | added |
---|
follow-up: 12 comment:7 by , 13 years ago
I think that the patch proposed by klaricmn would be the perfect solution to allow users to access the powerful feature represented by pixel functions even from python and other bindings.
See: http://lists.osgeo.org/pipermail/gdal-dev/2011-May/028737.html, #3367 and attachment:pixfun-plugin-20110513.tar.gz:ticket:3367.
In short: pixel functions can be supplied and registered using plugins (small C/C++ coding) and then, with the applied patch, they could be used from the python API etc.
comment:8 by , 13 years ago
Replying to rouault:
Yes, users of C API cannot add derived band. But they could neither register the pixel function, so you definitely need C++ to use those advanced features of the VRT driver. I think we are not too keen on extending more the VRT C API, as it can be difficult to guarantee its stability when the VRT driver evolves.
Sorry Even, I don't understand the above comment.
If my understanding is correct, GDALAddDerivedBandPixelFunc is in the C public API so users can register pixel function from C.
What am I missing?
comment:9 by , 13 years ago
Yeah, forget the part about GDALAddDerivedBandPixelFunc(). It is indeed in gdal.h, so in the C API
comment:10 by , 13 years ago
Replying to rouault:
[CUT]
I think we are not too keen on extending more the VRT C API, as it can be difficult to guarantee its stability when the VRT driver evolves.
Just in case you change your mind I've just attached a patch that extends the one written by klaricmn to handle also the SourceTransferType parameter.
The new patch also include autotests.
comment:11 by , 13 years ago
Milestone: | 1.8.1 → 1.9.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
OK, you finally convinced me by providing the tests ;-)
r22374 /trunk/ (2 files in 2 dirs): VRT: Recognize PixelFunctionType and SourceTransferType options in AddBand() for VRTDerivedRasterBand (#3925, patch contributed by klaricmn and antonio)
comment:12 by , 13 years ago
Replying to antonio:
I think that the patch proposed by klaricmn would be the perfect solution to allow users to access the powerful feature represented by pixel functions even from python and other bindings.
...and just to give credit where credit is due, the patched that I submitted was mostly/entirely written by bclaywell (my co-worker). I can't remember if I had my hands directly in this one at all or not. I submitted this and several other patches during a "submit all of our local patches" spree a few months back.
I'm not sure of the interest of the patch.
Why not just doing :