That should be relatively straightforward to adapt
GDALResampleChunk_AverageOrRMS_T to do sum. Reuse the average code path,
but just don't divide the sum by dfTotalWeight at lines 1418, 1473,
1688, 1700 and 1712. And error out if applied to a band with a color
table (cf line 4361)
For other algorithms, it could potentially be possible to re-use the
warping code with an adaptation layer like done in
GDALRasterBand::RasterIOResampled() in the bUseWarp case. Of course that
would be less performant than implementing a specific overview
resampling kernel which can assume that a source rectangle maps to a
target rectangle at the band level, while the warping code only process
pixel by pixel.
Le 21/09/2023 à 22:25, Michael Sumner via gdal-dev a écrit :
Can we aspire to translate having the same set of resampling
algorithms as the warper?
I see the warper adds min, max, mod, q1, q3, sum
I especially wanted sum for OVERVIEW_RESAMPLING in COG, and I can see
where it's done and ... can maybe see my way through that ... but
the 600 lines of code in GDALResampleChunk_AverageOrRMS_T kind of
reins in my confidence.
https://github.com/OSGeo/gdal/blob/26e7ff91504e0303434f440e6d19e58f2a206b45/gcore/overview.cpp#L1211C15-L1211C47
It came up as a need for statistical properties required for
overview-publishers, and while I think we can incrementally build up
the SUM-pyramid with external overivews via CLI it would be awesome to
have the same stats for the two resampling regimes.
Thank you
--
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsum...@gmail.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
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
