Le 22/01/2024 à 14:26, Robert Coup a écrit :
Hi Even,
Thanks for your reply!
On Fri, 19 Jan 2024 at 17:32, Even Rouault
<even.roua...@spatialys.com> wrote:
I can't think an easy way of doing what you want.
Is there a functional gap? /Conceptually/ it feels to me like
VRTRasterBand.ComplexSource.UseMaskBand should "mark" a pixel to be
nodata-equivalent (NaN?), and then VRTRasterBand.NoDataValue should
"write" the nodata-marked pixels with the value.
<VRTDataset ...>
...
<VRTRasterBand dataType="Int16" band="1">
<NoDataValue>-1</NoDataValue>
<ComplexSource>
<SourceFilename>in.tif</SourceFilename>
<SourceBand>1</SourceBand>
<UseMaskBand>true</UseMaskBand>
...
</ComplexSource>
...
</VRTRasterBand>
But maybe that's not how it's modelled inside?
The above declaration literally tells "use the mask band of band 1 of
in.tif and expose it as a Int16 band whose nodatavalue metadata is set
to -1". So no "intelligent" things like remapping the values of band 1
to either their native value or -1 depending on the value of the mask band.
Well, you can definitely do that using a VRT Python pixel
function, that
would essentially do your --calc expression
Thanks for confirming it's possible, I'll have a play.
From what I can see the python pixel functions are only called once,
Not sure what you mean by "called once". Well, they are called each time
IRasterIO() is called on the VRT band. So if you request 1x1 pixel at a
time, that's not going to be fast. But if you work on reasonably large
blocks, the setup cost of going through Python should be amortized.
use numpy and (IIUC) vectorised CPU operations...
Not totally sure what numpy does internally, but there shouldn't be any
measurable difference between a gdal_calc.py and the equivalent formula
put as a VRT Python pixel function.
would that make it faster/comparable to one of the C pixel functions
that's doing a naive array loop over rows & columns?
Potentially... That said if you'd want to use that in a multithreaded
application to read several VRTs from concurrent threads, then you'd hit
the Python GIL, so that wouldn't scale well (although it might
potentially be released by numpy when it goes to native code, so maybe
that's not so bad). But for single threaded, there's indeed the
potential that numpy based might be faster than the "naive" C pixel
functions.
A nice exercice for (Pythonist) contributors would be to add a -f VRT
capability to gdal_calc.py that would essentially automate the
writing
of such VRT using Python pixel functions. Just saying...
*adds to a long list of nice exercises*
Ah ah, this was actually a proposal to the wider audience. I'm sure
there are lots of people looking for ideas for a first nice contribution
to GDAL :-)
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
