[gdal-dev] VRTComplexSource with a LUT, proposal

[Saâd HESSANE]

As I said, I also propose to have the -filter parameter that write vrt with
the VRTKernelFilteredSource class.

Best regards.



2012/5/20 Saâd HESSANE <saad.hessane at gmail.com>

> Hi Even,
>
> The main goal of this proposal is to built using "gdalbuildvrt" VRT files
> containing LUT or filters.
>
> The patch that I send allow build VRT with LUT by specifying the -lutin
> and -lutout parameters.
> Ex :
>   gdalbuildvrt -lutin "0 1 2" -lutout "4 5 6" test.vrt test.tif
>
> We can discuss the fact that define two parameters (-lutin and -lutout) or
> just one parameter (-lut "0,4 1,5 2,6"). This is not a problem.
>
>
> 2012/5/19 Even Rouault <even.rouault at mines-paris.org>
>
>> Le samedi 19 mai 2012 18:58:05, Saâd HESSANE a écrit :
>> > Hi Even and thank you for the quick response.
>> >
>> > You should even not consider the VRTComplexSource class to be in the
>> public
>> >
>> > > API, so the visibility of its members is not significant. And playing
>> > > with them
>> > > from the outside isn't recommanded at all.
>> >
>> > The fact that you don't consider the class in the public API does not
>> > excuse the fact that this is a mistake encapsulation :)
>>
>> I agree the encapsulation isn't ideal, but unless I'm wrong, this class is
>> *not* in the public API. It is not marked as CPL_DLL exported, so on
>> Windows,
>> you should not be able to access it from the outside of the GDAL lib. On
>> Unix/Linux, as, by default (unless GDAL is configured with
>> --hide-internal-
>> symbols), all symbols are exported, you can technically use it however.
>>
>> > And apart from that, nothing prevents me to use a special driver to do
>> > specific things that are not directly provided by the public API.
>> > Currently I need to build a VRT, and the VRT driver are fine for that.
>> It's
>> > dirrectly use in the gdalbuildvrt utility for example. If the VRT
>> plugin is
>> > not safe to use, the solution is to correct it.
>>
>> There's always a trade off between exposing API and increasing maintenance
>> burden. The more API you expose, the more difficult it is to make changes
>> afterwards.
>>
>> > To read a VRT file outside from gdal I need to parse an XML file, so I
>> have
>> > to use another dependency (like xerces) to do just a small think.
>>
>> You don't need another dependency. You can use the CPL minixml API (see
>> cpl_minixml.h) that is used by the VRT driver itself for example.
>>
>> >
>> > Another argument is the VRTKernelFiltredSource. To set a kernel filtre
>> we
>> > don't have to set the attributes nKernelSize, padfKernelCoefs and
>> > bNormalized, because we can't (the attributes are protected). But the
>> API
>> > offers a setKernel that do exactly the same think that I hope the setLUT
>> > method do in the VRTComplexSource.
>>
>> If you can come with a patch, I'll consider including it, but I still
>> believe
>> you should not rely on that.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120520/1a3a358f/attachment.html