Re[2]: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Thanks for the answer, Hi list ! I was wondering why the Lanczos and cubicspline are available in gdal_warp and not gdaladdo ? Benoît, The overview builder and warper use quite different mechanisms so there is no close relationship between the resampling options available in each case. Ok, I think the best thing to do for me is to look at the source code... The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? It is my intention to add a cubic resampling option to the overview building for 1.7. I am not planning to add the other options. Are you not planning because there is nobody asking for (poor me) ? The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! I am surprised to be the first one to notice such a difference. I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. In theory it should be possible to programatically connect warpers to overview levels in cases where overview band objects have proper dataset parents - which is the case with GeoTIFF hosted overviews. For instance, this C entry point could likely be used with hSrcDS being the base datset, and hDstDS being the dataset for the overviews. One problem with this plan is that it is likely that overview datasets do not have proper geotransforms or coordinate systems. So you might need to push a geotransform onto the overview dataset (with GDALSetGeoTransform()) before calling GDALReprojectImage(). CPLErr CPL_DLL CPL_STDCALL GDALReprojectImage( GDALDatasetH hSrcDS, const char *pszSrcWKT, GDALDatasetH hDstDS, const char *pszDstWKT, GDALResampleAlg eResampleAlg, double dfWarpMemoryLimit, double dfMaxError, GDALProgressFunc pfnProgress, void *pProgressArg, GDALWarpOptions *psOptions ); Generally the warp api resamplers are not suitable for with a destination dataset with a radically lower resolution than the source. So I'd suggest doing it such that each overview is generated from the next higher resolution overview rather than always building from the base level. Ok. Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? There is something I am not sure to understand. You are saying to use the warp library directly from the overviewing mechanism. Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a library callable from the overviewing and warping codes ? I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) Note that the overview levels still need to be pre-created using normal mechanisms. Ok. Have to look. I'll take a look in the next days and will come back for help !! :) Regards, Benoît Andrieu b...@ixsea.com benoit.andr...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re[2]: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
Thanks for the answer Frank ! So in a first time I'll be looking at making a gdaladdo bis. By the way, do you know why Mapserver does only support nearest, average, bilinear, bicubic ? I thought it was using GDAL to do warping, but then it would natively support cubicspline and lanczos. I know that speed is a concern... ^^ By the way bis, I forgot to mention that we had some artifacts with gdalwarp yesterday. We are using FWTools 2.3.1. We wanted to merge several pictures at 20cm x 20cm resolution and make a 1m x 1m and a 4m x 4m. The pictures could be quite big : 3 x 3 pixels. First, we used gdalwarp to do all operations in a single one : merging and downsizing. But the resulting picture contained artifacts. In some areas, it is as if a nearest method was used instead of lanczos. Because of this, we then asked gdalwarp to make the downsizing. In a second call, we made the merging. There we did not find artifacts and it is ok for us to do like this. But I fear to have the same problems with bigger pictures. I will not be able to provide the pictures (sources or results) because of confidentiality agreements. But I could provide screenshots. Or try to reproduce on differents datasets. Regards, Benoît Andrieu -Message reçu- De: Frank Warmerdam warmer...@pobox.com À: Benoit Andrieu b...@ixsea.com Cc: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org Date: 30/03/2009 23:48 Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Benoit Andrieu wrote: The quality after downsizing images with gdalwarp is so perfect that I am now willing to include this in my overviews. Is there any chances to have this include in future releases or is there any difficulties I am not aware of ? It is my intention to add a cubic resampling option to the overview building for 1.7. I am not planning to add the other options. Are you not planning because there is nobody asking for (poor me) ? The image quality on our datasets is really amazing between merging with bilinear / cubicspline / Lanczos ! I am surprised to be the first one to notice such a difference. I will try to see if gdaladdo and gdalwarp give the same results. I have a doubt right now. Benoit, I personally would prefer not to further complicate the overview code with additional resampling types. However, I have an insistent client who will pay, and who might become grumpy if I did not oblige. Ok. Do you mean that producing a 1m x 1m image with 20cm x 20cm images could give bad results ? In this case things might not be too bad, but these resampling kernels basically have at most 4x4 kernels, so if you are doing 20:1 downsampling only a small fraction of the pixels are having any influence. On the other hand in them more typical 1:1 resampling case you get nice results as a small window of pixels in the area gets considered in the resampling. For 1 step radical downsampling something like average may give better results than 4x4 kernel resamplers. However, if downsampling is done stepwise (by powers of 2 for instance) then the 4x4 kernel resamplers may give good results all the way. There is something I am not sure to understand. You are saying to use the warp library directly from the overviewing mechanism. I am suggesting writing a small C application that would first generate normal overviews, and the use the warper to overwrite them with nicely downsampled imagery. Why can't I take the lanczos/cubicspline codes, separate it from the warping code to make a library callable from the overviewing and warping codes ? I think that the answer is a long one so if it is too much to ask, just say to me to look at the code ! ;) This would be messy. I am trying to avoid overcomplicating the overview code which is already very complicated. In fact it is already so complicated that I'm mortified about extending it with cubic resampling. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re[2]: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo
That sounds like bad news for my dreams ! :( I was planning to make a try with IPP on some parts of GDAL (warping, geometry rasterization). Did you make some profiling ? I would be interested to know the results ! Regards, Benoît Andrieu -Message reçu- De: Adam Nowacki no...@xpam.de À: gdal-dev@lists.osgeo.org Gdal-Dev gdal-dev@lists.osgeo.org Date: 31/03/2009 00:06 Objet: Re: [gdal-dev] Availability of Lanczos and cubicspline in gdaladdo Seth Price wrote: I actually hope to be addressing performance in my GSoC project. I'm interested in rewriting the GDAL resampling code to CUDA, so the graphics card does the hard work. For example, instead of processing one pixel at a time, the latest GeForce GTX 260 would be able to process 216. I'm hoping for CUDA to be 50 to 100 times faster. Make sure you're using GDAL 1.6 or later, I recently rewrote the regular Lanczos/cubicspline warping code to be much faster. ~Seth You can achieve pretty amazing speeds on the CPU alone. I have a SSE3 (would be trivial to rewrite as plain old SSE, probably a bit slower) Lanczos sampler with 4x4 kernel that runs at ~70 000 000 samples per second with float data type on a 2.33GHz Intel Xeon E5410 (one thread). I was considering porting the sampler to GDAL but found that I would have to rewrite the whole warping code to get any useful speed boost, including heavily optimizing coordinate transformations. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
