<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 22/01/2024 à 14:26, Robert Coup a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAFLLRpL3z_WMG1RQL3B4gEwsM3DSJS_xpP_eBNhJM6zFyYqy8A@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">Hi Even,
          <div><br>
          </div>
          <div>Thanks for your reply!</div>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Fri, 19 Jan 2024 at
            17:32, Even Rouault <<a
              href="mailto:even.rouault@spatialys.com"
              moz-do-not-send="true" class="moz-txt-link-freetext">even.rouault@spatialys.com</a>>
            wrote:</div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
            I can't think an easy way of doing what you want.<br>
          </blockquote>
          <div><br>
          </div>
          <div>Is there a functional gap? <i>Conceptually</i> it feels
            to me like <font face="monospace">VRTRasterBand.ComplexSource.UseMaskBand</font>
            should "mark" a pixel to be nodata-equivalent (NaN?), and
            then <font face="monospace">VRTRasterBand.NoDataValue</font>
            should "write" the nodata-marked pixels with the value.</div>
          <div><br>
          </div>
        </div>
        <blockquote style="margin:0 0 0 40px;border:none;padding:0px">
          <div class="gmail_quote">
            <div><font face="monospace"><VRTDataset ...></font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">  ...</font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">  <VRTRasterBand
                dataType="Int16" band="1"></font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">   
                <NoDataValue>-1</NoDataValue></font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">    <ComplexSource></font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">     
                <SourceFilename>in.tif</SourceFilename></font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">     
                <SourceBand>1</SourceBand></font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">     
                <UseMaskBand>true</UseMaskBand></font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">      ...</font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">    </ComplexSource></font></div>
            <div><font face="monospace">    ...</font></div>
          </div>
          <div class="gmail_quote">
            <div><font face="monospace">  </VRTRasterBand></font></div>
          </div>
        </blockquote>
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>But maybe that's not how it's modelled inside?</div>
        </div>
      </div>
    </blockquote>
    <p>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.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAFLLRpL3z_WMG1RQL3B4gEwsM3DSJS_xpP_eBNhJM6zFyYqy8A@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
            <br>
            Well, you can definitely do that using a VRT Python pixel
            function, that <br>
            would essentially do your --calc expression<br>
          </blockquote>
          <div><br>
          </div>
          <div>Thanks for confirming it's possible, I'll have a play. </div>
          <div><br>
          </div>
          <div>From what I can see the python pixel functions are only
            called once,</div>
        </div>
      </div>
    </blockquote>
    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.<br>
    <blockquote type="cite"
cite="mid:CAFLLRpL3z_WMG1RQL3B4gEwsM3DSJS_xpP_eBNhJM6zFyYqy8A@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> use numpy and (IIUC) vectorised CPU operations...</div>
        </div>
      </div>
    </blockquote>
    <p>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.<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
cite="mid:CAFLLRpL3z_WMG1RQL3B4gEwsM3DSJS_xpP_eBNhJM6zFyYqy8A@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div> would that make it faster/comparable to one of the C
            pixel functions that's doing a naive array loop over rows
            & columns?</div>
        </div>
      </div>
    </blockquote>
    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.<br>
    <blockquote type="cite"
cite="mid:CAFLLRpL3z_WMG1RQL3B4gEwsM3DSJS_xpP_eBNhJM6zFyYqy8A@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
            A nice exercice for (Pythonist) contributors would be to add
            a -f VRT <br>
            capability to gdal_calc.py that would essentially automate
            the writing <br>
            of such VRT using Python pixel functions. Just saying...</blockquote>
          <div><br>
          </div>
          <div>*adds to a long list of nice exercises*</div>
        </div>
      </div>
    </blockquote>
    <p>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 :-)</p>
    <p>Even</p>
    <br>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </body>
</html>