[gdal-dev] Any difference between VRT SimpleSource and no-op ComplexSource?

[Laurențiu Nicola]

On Thu, Dec 21, 2023, at 15:51, Even Rouault wrote:
> It only uses a ComplexSource when it needs to, that is to say when there is nodata or a mask band.
> 
I didn't realize this. I think I'm hitting a corner case with -separate, which is practically the only way I've ever used it:

$ gdalbuildvrt test.vrt T35TMK_20230520T090559_B02_10m.jp2 && cat test.vrt 
0...10...20...30...40...50...60...70...80...90...100 - done.
<VRTDataset rasterXSize="10980" rasterYSize="10980">
  <SRS dataAxisToSRSAxisMapping="1,2">PROJCS["WGS 84 / UTM zone 35N",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",27],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32635"]]</SRS>
  <GeoTransform>  3.9996000000000000e+05,  1.0000000000000000e+01,  0.0000000000000000e+00,  5.0000400000000000e+06,  0.0000000000000000e+00, -1.0000000000000000e+01</GeoTransform>
  <VRTRasterBand dataType="UInt16" band="1">
    <ColorInterp>Gray</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">T35TMK_20230520T090559_B02_10m.jp2</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="10980" RasterYSize="10980" DataType="UInt16" BlockXSize="1024" BlockYSize="1024" />
      <SrcRect xOff="0" yOff="0" xSize="10980" ySize="10980" />
      <DstRect xOff="0" yOff="0" xSize="10980" ySize="10980" />
    </SimpleSource>
  </VRTRasterBand>
  <OverviewList resampling="nearest">2 4 8 16</OverviewList>
</VRTDataset>

$ gdalbuildvrt -separate test.vrt T35TMK_20230520T090559_B02_10m.jp2 && cat test.vrt
0...10...20...30...40...50...60...70...80...90...100 - done.
<VRTDataset rasterXSize="10980" rasterYSize="10980">
  <SRS dataAxisToSRSAxisMapping="1,2">PROJCS["WGS 84 / UTM zone 35N",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",27],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32635"]]</SRS>
  <GeoTransform>  3.9996000000000000e+05,  1.0000000000000000e+01,  0.0000000000000000e+00,  5.0000400000000000e+06,  0.0000000000000000e+00, -1.0000000000000000e+01</GeoTransform>
  <VRTRasterBand dataType="UInt16" band="1">
    <ComplexSource>
      <SourceFilename relativeToVRT="1">T35TMK_20230520T090559_B02_10m.jp2</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="10980" RasterYSize="10980" DataType="UInt16" BlockXSize="1024" BlockYSize="1024" />
      <SrcRect xOff="0" yOff="0" xSize="10980" ySize="10980" />
      <DstRect xOff="0" yOff="0" xSize="10980" ySize="10980" />
    </ComplexSource>
  </VRTRasterBand>
</VRTDataset>

> Otherwise it will use SimpleSource. There is a performance hit in using ComplexSource when it is not needed. In 3.8, there has been an optimization to improve ComplexSource performance in common nodata-only scenarios: cf https://github.com/OSGeo/gdal/commit/cd67491d3909f5f05160fa209609b38d973c42de
Oh, that's great!

PS: are there good reasons for not allowing -separate for multi-band inputs (by including all bands) or propagating the input block size if it's the same for all of them?

Laurentiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231221/2964c44c/attachment-0001.htm>