xsize ignored in VRT

[westside]

Attached are two images orig.tif and output.tif. Orig.tif is a 1024x1024 image. I defined the following VRT:

<VRTDataset rasterXSize="1024" rasterYSize="1024"> <ColorInterp>Gray</ColorInterp> <VRTRasterBand dataType="Byte" band="1">

<SimpleSource>

<SourceFileName relativetoVRT="1">orig.tif</SourceFileName> <SrcRect xOff="0" yOff="0" xSize="512" ySize="1024"/> <DstRect xOff="0" yOff="0" xSize="512" ySize="1024"/>

</SimpleSource>

</VRTRasterBand> </VRTDataset>

It was my undertanding that this would select all lines of orig.tif and the first 512 pixels. This is not the case. The entire image is copied into the output.tif image.

Attached are the vrt the orig.tif and output.tif images.

I'm using GDAL 1.4.

[westside]

To be clear it was my understanding that a 512x1024 portion of orig.tif would be written into output.tif. This is not the case.

-e

[warmerdam]

The problem is that VRTSimpleSource::GetSrcDstWindow() does not restrict the computed window based on DstRect. I shall return to fixing then when I have a bit more time.

[westside]

Looked at this a bit and I don't see how the RasterIO method can be used in this case. The parameters of this method don't seem to support the right mapping even if GetSrcDstWindow returns the appropriate sizes. afaict, unless there's another method I don't know about, it appears that the each line needs written separately in a loop.

[warmerdam]

Ethan,

I'm not sure why you find that to be the case. In any event, I have modified GetSrcDstWindow() in trunk and 1.4 branch in a way that seems to fix the problem. Also, I have added a test in autotest/gcore/vrt_read.py to regression test this issue.

Thanks for the report!

[warmerdam]

The previous fix has been discovered to be defective in the case where the source and destination windows are not set (as is allowed). This is fixed in 1.4, trunk and 1.4-esri now, and an appropriate addition made to the trunk test suite.