Gaussian pyramid in gdal
|Reported by:||warmerdam||Owned by:||Even Rouault|
|Cc:||krzystek@…, Even Rouault, warmerdam@…|
From Peter Krzystek:
it took me a while to find time to do something on that subject. Meanwhile I am working with gdal version 1.4.2 and have successfully added the 3x3 Gaussian kernel. I have tested it with a large number of sample Tiff files (tiled/untiled) covering the following formats.
1x8 (uncompressed, lzw, packbits) 1x8 Pallete (uncompressed, lzw, packbits) 3x8 (uncompressed, lzw, packbits) 4x8 (uncompressed, lzw, packbits) 1x16 (uncompressed, lzw, packbits) 3x16 (uncompressed, lzw, packbits) 4x16 (uncompressed, lzw, packbits)
All the uncompressed formats - either tiled or untiled - show no problems. However, as you probably know, lzw and packbits tiff formats do not work properly. The only workaround in this case - as suggested in bug report 1205 (
) is to convert the image to an uncompressed image, do the image pyramid, and to use geotiffcp to convert it back to either lzw or packbits.
Please find attached the piece of code that includes the 3x3 Gaussian. The change affects only the file "overview.cpp" and the functions "GDALRegenerateOverviews" and "GDALDownsampleChunk32RAs". Since I am not an experienced contributor to gdal code I send you the file as a compressed document. I hope this is fine. If not, could you please give me a short hint how I can get a user ID etc. and should proceed.
If you can accept the code change please let me know.
P.S. The implementation of the Gaussian kernel follows the code for the option "AVER" that does the filtering in each scanline. Thus, no decomposition of the linear kernel is applied that would reduce the number of instructions (i.e. multiplications). However, since the kernel is only 3x3 this little drawback will not cause a severe time delay. If the size of the kernel (e.g. 3,5, etc.) should be an option, another parameter needs to be passed to the function "GDALDownsampleChunk32RAs".