Re: [gdal-dev] pansharpen subset of multispectral bands

Thanks for that explanation, Even. Is this to say, if i have a panchromatic band that spans coastal-blue-green-red-rededge1-rededge2-rededge2-nir, and I only have blue-green-red-NIR, that pansharpening is invalid? The math works out, but it may not be a spectrally consistent result. I'm able to

Re: [gdal-dev] pansharpen subset of multispectral bands

> in the event that we are provided only 4 bands, but from an 8-band system, will this still hold? It is what we have to work with, unfortunately or not. Yes, obviously, the example generalizes to other number of bands. So, providing either |band_nums=[1,2,3,4]| along with weights and extract

Re: [gdal-dev] pansharpen subset of multispectral bands

There is a band_nums parameter (and weights) you can provide to gdal_pansharpen, which led to me thinking about this question in the first place. band_nums: Optional[Sequence[int]] = None weights: Optional[Sequence[float]] = None So, providing either band_nums=[1,2,3,4] along with weights and

Re: [gdal-dev] pansharpen subset of multispectral bands

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 

Re: [gdal-dev] pansharpen subset of multispectral bands

Thank you, Even! In the event that we are provided only 4 bands, but from an 8-band system, will this still hold? It is what we have to work with, unfortunately or not. -Joe From: Even Rouault Sent: Thursday, January 9, 2025 13:24 To: Joe McGlinchy ; gdal-dev@li

Re: [gdal-dev] pansharpen subset of multispectral bands

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

Re: [gdal-dev] Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release

+1 Dan On Thu, Jan 9, 2025 at 7:14 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release > > Starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Butcher of all kind

Re: [gdal-dev] GDAL 3.10.1 RC2 is available (was Re: GDAL 3.10.1 release candidate available)

Yes, this works (with a directory name of "autotest"). On Thu, Jan 9, 2025 at 2:24 PM Even Rouault wrote: > > Le 09/01/2025 à 20:08, Daniel Baston a écrit : > > It looks like the packaged gdalautotest snapshot does not include a > > pytest.ini, which causes many warnings to be generated > > (Pyt

[gdal-dev] pansharpen subset of multispectral bands

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 pansharp

Re: [gdal-dev] GDAL 3.10.1 RC2 is available (was Re: GDAL 3.10.1 release candidate available)

Le 09/01/2025 à 20:08, Daniel Baston a écrit : It looks like the packaged gdalautotest snapshot does not include a pytest.ini, which causes many warnings to be generated (PytestUnknownMarkWarning) and also some collection errors such as this one. Not sure anyone has done that exercice before

Re: [gdal-dev] GDAL 3.10.1 RC2 is available (was Re: GDAL 3.10.1 release candidate available)

It looks like the packaged gdalautotest snapshot does not include a pytest.ini, which causes many warnings to be generated (PytestUnknownMarkWarning) and also some collection errors such as this one. ― ERROR collecting gdrivers/data/s104/generate_tes

Re: [gdal-dev] Issue with Custom Transformation Pipeline in GDALReprojectImage

Anyway a proper pipeline I use for years is: +proj=pipeline +step +inv +proj=krovak +lat_0=49.5 +lon_0=24.8 +alpha=30.2881397527778 +k=0. +x_0=0 +y_0=0 +ellps=bessel +step +inv +proj=hgridshift +grids=Slovakia_JTSK03_to_JTSK.gsb +step +proj=krovak +lat_0=49.5 +lon_0=24.8

Re: [gdal-dev] Issue with Custom Transformation Pipeline in GDALReprojectImage

On Thu, Jan 9, 2025 at 4:53 PM Even Rouault wrote: > > > Regarding the pipeline, it could be a bad copy-paste or garbled by > > ChatGPT 😀. > > I wouldn't trust ChatGPT to come with geodesic-relevant pipelines... If > you aren't really sure about what you are doing, you'd better let PROJ > infer a

Re: [gdal-dev] Issue with Custom Transformation Pipeline in GDALReprojectImage

Regarding the pipeline, it could be a bad copy-paste or garbled by ChatGPT 😀. I wouldn't trust ChatGPT to come with geodesic-relevant pipelines... If you aren't really sure about what you are doing, you'd better let PROJ infer a reasonable pipeline. I'm also questioning the use of the gr

Re: [gdal-dev] Issue with Custom Transformation Pipeline in GDALReprojectImage

Thank you Even, I went more low-level and successfully used GDALChunkAndWarpImage . I also posted answer on SO . Regarding the pipeline, it

Re: [gdal-dev] Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release

+1 Howard > On Jan 9, 2025, at 7:24 AM, Rahkonen Jukka via gdal-dev > wrote: > > +1 > > -Jukka Rahkonen- > > -Alkuperäinen viesti- > Lähettäjä: gdal-dev Puolesta Even Rouault > via gdal-dev > Lähetetty: torstai 9. tammikuuta 2025 14.14 > Vastaanottaja: gdal-dev@lists.osgeo.org > Ai

Re: [gdal-dev] Is it possible to write custom CRS WKTs within a GeoTiff?

Le 09/01/2025 à 14:29, Paul Harwood a écrit : "If you can sacrifice the ellipsoidal height axis to avoid using a Projected 3D CRS, which is a bit of a geodetic dubious object (don't ask me more, but minds more enlightned than me question the soundness of using an ellipsoidal h

Re: [gdal-dev] Is it possible to write custom CRS WKTs within a GeoTiff?

"If you can sacrifice the ellipsoidal height axis to avoid using a > Projected 3D CRS, which is a bit of a geodetic dubious object (don't ask me > more, but minds more enlightned than me question the soundness of using an > ellipsoidal heights with a projected CRS)” > > > I won’t ask you more :) bu

Re: [gdal-dev] Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release

+1 -Jukka Rahkonen- -Alkuperäinen viesti- Lähettäjä: gdal-dev Puolesta Even Rouault via gdal-dev Lähetetty: torstai 9. tammikuuta 2025 14.14 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: [gdal-dev] Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release Hi, Motion: approve GDAL 3.10.1 RC2 a

Re: [gdal-dev] Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release

+1 Javier On Thu, 9 Jan 2025 at 13:14, Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release > > Starting with my +1 > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > Butcher of all kin

Re: [gdal-dev] Issue with Custom Transformation Pipeline in GDALReprojectImage

Martin, GDALReprojectImage() expects that a correct geotransform is already set on the target dataset. You may use GDALSuggestedWarpOutput2() to get a guessed geotransform Otherwise for full automated way, you may also using the C function GDALWarp(). By the way, your below pipeline looks

[gdal-dev] Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release

Hi, Motion: approve GDAL 3.10.1 RC2 as 3.10.1 release Starting with my +1 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] Issue with Custom Transformation Pipeline in GDALReprojectImage

Dear GDAL developers and users, I am facing an issue where a custom transformation pipeline defined using PROJ's +proj=pipeline is not being applied when using GDALReprojectImage. The pipeline appears in the debug logs (PROJ_TRACE), but the output image does not reflect the expected transformation