[gdal-dev] Warp with different band types?

[Idan Miara]

Thanks Even!

For my case, max(data types) is good enough, but I see that for the general
case calling this function might be a better option.

I couldn't find a reference for GDALWarpResolveWorkingDataType in the
python wrappers, or the warp tester:
https://github.com/OSGeo/gdal/blob/master/autotest/alg/warp.py

Looking at
https://github.com/OSGeo/gdal/blob/master/autotest/cpp/test_alg.cpp#L89
I couldn't find a test that is considering two bands with different data
types.

I was expecting that, at least in the python version, gdal.Warp will call
this function internally before warping and not take the first data type as
a default.

Idan

On Mon, 23 Aug 2021 at 11:51, Even Rouault <even.rouault at spatialys.com>
wrote:

> Idan,
>
> The warping kernel works on a multiple band dataset by using a single
> working data type, which should be the "max" of the types of the input
> bands, so here int16. I believe this is working, but here the issue is more
> at the creation of the dataset itself than during the warping. This is due
> to
> https://github.com/OSGeo/gdal/blob/3302b5c9cb62191df3409676aa97fced07c92c3b/gdal/apps/gdalwarp_lib.cpp#L3017
> . GDALWarpResolveWorkingDataType() should likely be used instead
>
> Even
> Le 23/08/2021 à 00:58, Idan Miara a écrit :
>
> Hi all,
>
> I was trying to warp a ds with a byte band and an int16 band and got a ds
> with two byte band.
> Is warp using the first band data type for all the output bands?
> Is that a bug?
>
> If multiple band types are not supported - maybe max(band types) could be
> a better default (assuming no explicit output type) ?
>
> Kind regards,
> Idan
>
>
> _______________________________________________
> gdal-dev mailing listgdal-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- 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/20210825/29612e05/attachment.html>