[gdal-dev] pansharpen subset of multispectral bands
Barry DeZonia
bdezonia at gmail.com
Thu Jan 9 13:04:48 PST 2025
Does that snippet of code need to be that way? It seems it could
pretty easily be changed to work a band at a time and a weight of zero
would contribute nothing. Now I do not know the domain at all and
maybe that violates some assumptions. Curious as to what you think.
On Thu, Jan 9, 2025 at 2:36 PM Even Rouault via gdal-dev
<gdal-dev at lists.osgeo.org> wrote:
>
>
> Le 09/01/2025 à 20:27, Joe McGlinchy via gdal-dev a écrit :
>
> Hello,
>
> I'm wanting to pansharpen only a subset of multispectral bands I have available. Say for instance I have blue-green-red-nir, and a panchromatic band, I can calculate the relative weights to specify when using `gdal_pansharpen` on the full multispectral dataset. If I want to only pansharpen, for example, the red and NIR bands, is it best to perform the pansharpening on the full dataset and only retain the bands I need? Or can i provide only the weights specific to the bands I want to pansharpen? If I can do the latter (which I can, given the parameter set to `gdal_pansharpen`), do I need to recalculate those weights, or only provide the subset of weights for those specific bands?
>
> Given the formula at https://gdal.org/en/stable/drivers/raster/vrt.html#gdal-vrttut-pansharpen
>
> pseudo_panchro[pixel] = sum(weight[i] * spectral[pixel][i] for i=0 to nb_spectral_bands-1)
> ratio = panchro[pixel] / pseudo_panchro[pixel]
> for i=0 to nb_spectral_bands-1:
> output_value[pixel][i] = input_value[pixel][i] * ratio
>
>
> if you only provide a subset of the input spectral bands, you won't be able to reconstruct a plausible pseudo_panchro values, hence the scaling ratio will not be accurate.
>
>
> If your spectral dataset has bands in the R,G,B,NIR order, you can achieve what you want with:
>
>
> $ gdal_pansharpen panchro.tif rgbnir.tif,band=1 rgbnir.tif,band=2 rgbnir.tif,band=3 rgbnir.tif,band=4 out.tif -b 1 -b 4
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
More information about the gdal-dev
mailing list