[gdal-dev] Discrepancy in utilizing overviews with gdalwarp

[Denis Rykov]

Thank you, Jukka, for reproducing the behavior and explaining the reason
behind it!

On Mon, Jun 10, 2024 at 9:19 AM Rahkonen Jukka <
jukka.rahkonen at maanmittauslaitos.fi> wrote:

> Hi,
>
>
>
> Those two commands behave in quite different ways. With “-oo
> OVERVIEW_LEVEL=1” the output size is the size of the second overview. In my
> test case the original has 12000 x 12000 pixels and the command creates a
> 3000 x 3000 sized output
>
>
>
> GDAL: GDALOverviewDataset(vrttest.vrt, this=000001CB3D728890) creation.
>
> GDAL: Using GTiff driver
>
> GDAL: Computing area of interest: 26.8805, 63.2011, 27, 63.255
>
> Creating output file that is 3000P x 3000L.
>
> …
>
> GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=0,0,3000x3000 Dst=0,0,3000x3000
>
> ...10...20...30...40...50...60...70...80...90...100 - done.
>
>
>
> With -ovr 1 the output has the size of the full resolution image, 12000 x
> 12000 pixels, even the data is read from the 3000 x 3000 overview. The
> pixels will be upsampled.
>
>
>
> GDAL: Using GTiff driver
>
> GDAL: Computing area of interest: 26.8805, 63.2011, 27, 63.255
>
> Creating output file that is 12000P x 12000L.
>
> WARP: Selecting overview level 1 for vrttest.vrt
>
> …
>
> GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=0,0,1500x750 Dst=0,0,6000x3000
>
> ...10.GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=1500,0,1500x750 Dst=6000,0,6000x3000
>
> ..20..GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=0,750,1500x750 Dst=0,3000,6000x3000
>
> .30...GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=1500,750,1500x750 Dst=6000,3000,6000x3000
>
> 40...50GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=0,1500,1500x750 Dst=0,6000,6000x3000
>
> ...60.GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=1500,1500,1500x750 Dst=6000,6000,6000x3000
>
> ..70..GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=0,2250,1500x750 Dst=0,9000,6000x3000
>
> .80...GDAL: GDALWarpKernel()::GWKNearestNoMasksOrDstDensityOnlyByte()
> Src=1500,2250,1500x750 Dst=6000,9000,6000x3000
>
> 90...100 - done.
>
> GDAL: Flushing dirty blocks:
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
>
>
> The behavior is the same when using a TIFF with internal overviews as
> input instead of VRT. Obviously the -ovr option has been designed to force
> the use of some better-quality overview as source data when warping yields
> a smaller, downsampled image. The forced upsampling does not make much
> sense to me. I wonder if gdalwarp should even allow that?
>
>
>
> The gdal_translate utility has also -ovr option
> https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-ovr.
> It behaves in a different way  when it comes to the size of the output, but
> with gdal_translate it makes sense.
>
> “When -ovr is specified to an integer value, and none of -outsize and -tr
> is specified, the size of the overview will be used as the output size.”
>
>
>
> Maybe the thing to do is to improve the documentation of the gdalwarp
> option https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-ovr and
> mention that this option does not have on effect on the size of the output.
>
>
>
> -Jukka Rahkonen-
>
>
>
>
>
>
>
>
>
> *Lähettäjä:* gdal-dev <gdal-dev-bounces at lists.osgeo.org> *Puolesta *Denis
> Rykov via gdal-dev
> *Lähetetty:* maanantai 10. kesäkuuta 2024 2.27
> *Vastaanottaja:* gdal dev <gdal-dev at lists.osgeo.org>
> *Aihe:* [gdal-dev] Discrepancy in utilizing overviews with gdalwarp
>
>
>
> I'd anticipate that both commands would yield the same outcome:
>
> $ gdalwarp -oo OVERVIEW_LEVEL=1 -dstalpha input.vrt ovr1.tif
> $ gdalwarp -ovr 1 -dstalpha input.vrt ovr1.tif
>
>
>
> However, the reality is different. The first command behaves as intended,
> utilizing overviews from *.vrt.ovr, while the second command operates
> noticeably slower, seemingly disregarding the overviews.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240610/4ff4d66e/attachment.htm>