[gdal-dev] Suggestion for API addition

[David Strip]

On 11/11/2012 12:56 PM, Even Rouault wrote:
>> GDALRasterBand::WriteCropToBand(int nCropSizeX, // width of the cropped
>> region int nCropSizeY, // height of the cropped region int nXOffset,   //
>> offset to the left edge of the cropped region int nYOffset,   // offset to
>> the top of the cropped region void * pBuf,    // pointer to the buffer
>> (uncropped) GDALDataType eBufType, // data type in the buffer int
>> nPixelSpace, // byte offset from one pixel to the next int nLineSpace)  //
>> byte offset from one line to the next {
>>     void * pData = pBuf + nYOffset * nLineSpace + nXOffset * nPixelSpace;
>>     this->RasterIO(GF_Write, 0, 0, this->nRasterXSize, this->nRasterYSize,
>>                    pData, nCropSizeX, nCropSizeY, eBuftype, nPixelSpace,
>> nLineSpace); }
>>
>>   The code is obviously not very complicated. The value is that when you're
>> reading code you can tell immediately that what's happening is the buffer
>> is being cropped and written. If written directly in terms of RasterIO the
>> intent is buried in the computation of the parameters, making it less
>> clear.
> Your implementation is more about rescaling than cropping (
> http://en.wikipedia.org/wiki/Cropping_%28image%29 ). For me cropping implies
> at least working with a subwindow of the original image.
>
> Sorry, but I still think this is going to confuse people more than help them.
>
now it's my turn to be confused.
This is pixel-by-pixel copy of a subset of the input pixels. It is a 
subwindow of the original image, exactly as you say.
I'm taking an m x n input image and copying p x q pixels (p <= m, q <=n) 
into p x q pixels in the band. The scale is unchanged.