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