[gdal-dev] PNeo pan-sharpening post 3.7.0

[Even Rouault]

There's a whole discussion starting at comment 
https://github.com/OSGeo/gdal/pull/7256#issuecomment-1433318699 about 
how the old approach implicitly assuming same georeferencing for MS and 
PAN bands could be wrong for some data products, which could lead to 
increasing errors on right and bottom edges of images. It was decided 
that it was better for pansharpening to require having explicit 
geotransform in its inputs rather than making possibly incorrect guesses.

Even

Le 15/07/2023 à 16:13, Ferdinand a écrit :
> Hi Evan,
>
> Thanks for the response, I'll give it a go.
> As you are on the ticket I mentioned, I assume the rationale behind 
> the change was to remove the implicit assumption of overlap?
> Was there also a subpixel shift then when doing it the "old" way?
>
> Cheers,
>
> Ferdi
>
> On Fri, Jul 14, 2023 at 10:50 PM Even Rouault 
> <even.rouault at spatialys.com> wrote:
>
>     Ferdinand,
>
>     you can for example use "gdal_edit.py -ro -a_ullr X1 Y1 X2 Y2
>     your.tif" to create a geotransform in a sidecar .aux.xml file.  If
>     the pan and ms images have the same extent, you could possibly
>     just use -a_ullr 0 0 1 -1 (untested though). This hypothesis is
>     not totally true as there's some subpixel shift for those products
>     between the pan and ms bands if I remember well, so you might need
>     to tune that a bit to get optimal results, but generally assuming
>     same extent should give you already a decent result.
>
>     Even
>
>     Le 14/07/2023 à 17:36, Ferdinand a écrit :
>>     Hi all,
>>
>>     We do stereo photogrammetry on Pleiades/PNeo images, and in one
>>     case we run our algorithms on pansharpened images.
>>
>>     Our workflow therefore was that we would pan-sharpen the images
>>     and then run our stereo processing (using the panchromatic RPC
>>     model for the pansharpened image).
>>
>>     However, with the change in this PR:
>>     https://github.com/OSGeo/gdal/pull/7373 which was integrated into
>>     release 3.7.0, this is no longer possible. gdal_pansharpen.py now
>>     gives: `RuntimeError: Panchromatic band has no associated
>>     geotransform`.
>>
>>     What is the recommended workflow for this now? We can't
>>     orthorectify the images first, as we need the raw row/column
>>     information in the image in order for the photogrammetry
>>     processing to work.
>>
>>     Is there some other way to add a geotransform that does not
>>     require warping the image?
>>
>>
>>     Cheers,
>>
>>     Ferdi
>>
>>     _______________________________________________
>>     gdal-dev mailing list
>>     gdal-dev at lists.osgeo.org
>>     https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>     -- 
>     http://www.spatialys.com
>     My software is free, but my time generally not.
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230715/9d8fa2a0/attachment.htm>