[gdal-dev] Convert alpha to nodata?

[Even Rouault]

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.rouault at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240122/5258b5a4/attachment.htm>