Re: [gdal-dev] Motion: Commit Access for Kirk McKelvey
Le samedi 18 décembre 2010 01:09:28, Frank Warmerdam a écrit : Folks, Motion: Extend Commit Priveledges for Kirk McKelvey. +1 Even ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Performance improvment for gdal_retile
Some last comment about the test case, the current source checks test_gdal_retile_2() ds.GetRasterBand(4).Checksum() != 35 ds.GetRasterBand(4).Checksum() != 35 If I run this on a Linux Intel 32 bit configuration, it has to be ds.GetRasterBand(4).Checksum() != 283 ds.GetRasterBand(4).Checksum() != 122 Doing the same on a Linux AMD 64 Bit configuration, the values should be ds.GetRasterBand(4).Checksum() != 283 ds.GetRasterBand(4).Checksum() != 126 It seems that the cecksum is dependent on the platform. Is this desirable ? Could this cause some headaches later ? Cheers Christian This message was sent using IMP, the Internet Messaging Program. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: OpenCL, GDAL, and You
Hi, Gave this a try on Windows (relatively simple to build) with CUDA and indeed the difference in speed is big. Petty that the result is quite broken. My test was with this projection gdalwarp -t_srs +proj=sinu mundo.tiff lixo32.tiff Joaquim I'm working on the trunk OpenCL build on my Mac now. ** First, on my mac I get an error at the end of make: [...] ./ogr/.libs/ogr_srs_xml.o ./ogr/.libs/ograssemblepolygon.o ./ogr/.libs/ogr2gmlgeometry.o ./ogr/.libs/gml2ogrgeometry.o ./ogr/.libs/ogr_expat.o /opt/local/lib/libsqlite3.dylib -L/opt/local/lib -L/usr/local/lib /usr/local/lib/libexpat.dylib /usr/local/lib/libjpeg.dylib /usr/local/lib/libtiff.dylib /usr/local/lib/libpng12.dylib -lpthread -ldl /opt/local/lib/libcurl.dylib /opt/local/lib/libidn.dylib -lssl -lcrypto -lz -lOpenCL-install_name /usr/local/lib/libgdal.1.dylib -compatibility_version 16 -current_version 16.0 -Wl,-single_module ld: library not found for -lOpenCL collect2: ld returned 1 exit status make[1]: *** [libgdal.la] Error 1 make: *** [check-lib] Error 2 seth:gdal-svn-trunk-2010.12.17 sprice$ To fix this, I changed OPENCL_LIB = -lOpenCL to OPENCL_LIB = -framework OpenCL in GDALMmake.opt. * Why is USE_CLAMP_TO_DST_FLOAT in there? I would think that is required even if it isn't on ATI. I'm not sure who inserted its use, but I'm just wondering if the reasoning is documented somewhere. * I had to make this change to alg/gdalwarpkernel_opencl.c to get it to build without a build option error. @@ -1168,7 +1168,7 @@ //Assemble the compiler arg string for speed. All invariants should be defined here. sprintf(buffer, -cl-fast-relaxed-math -Werror -D FALSE=0 -D TRUE=1 -%s +%s -D iSrcWidth=%d -D iSrcHeight=%d -D iDstWidth=%d -D iDstHeight=%d -D useUnifiedSrcDensity=%d -D useUnifiedSrcValid=%d -D useDstDensity=%d -D useDstValid=%d -D useImag=%d @@ -1176,9 +1176,9 @@ -D nXRadius=%d -D nYRadius=%d -D nFiltInitX=%d -D nFiltInitY=%d -D PI=%015.15lff -D outType=%s -D dstMinVal=%015.15lff -D dstMaxVal=%015.15lff -D useDstNoDataReal=%d -D vecf=%s %s -D doCubicSpline=%d --D useUseBandSrcValid=%d -D iCoordMult=%d, +-D useUseBandSrcValid=%d -D iCoordMult=%d , /* FIXME: Is it really a ATI specific thing ? */ -(warper-imageFormat == CL_FLOAT warper-bIsATI) ? -D USE_CLAMP_TO_DST_FLOAT=1 : , +(warper-imageFormat == CL_FLOAT warper-bIsATI) ? -D USE_CLAMP_TO_DST_FLOAT=1 : , warper-srcWidth, warper-srcHeight, warper-dstWidth, warper-dstHeight, warper-useUnifiedSrcDensity, warper-useUnifiedSrcValid, warper-useDstDensity, warper-useDstValid, warper-imagWorkCL != NULL, After doing all of the above to make things compile, I don't get the bug described below. I'm working off of the latest trunk daily. ~Seth On Dec 8, 2010, at 1:12 PM, Even Rouault wrote: Seth, Thanks for your help. It's more than a little strange that none of those image sizes work. Perhaps it's a problem with the image format? Can you verify that the given format should work? The image format was CL_UNORM_INT8 (for GDT_Byte) Looking at the spec, it might also be a problem with the 'sz' argument. What value is that passing? It's 1. I managed to found the following workaround that enables gdalwarp to complete (see http://trac.osgeo.org/gdal/changeset/21220 that basically passes a dummy buffer instead of a NULL pointer). However the visual result of the warping is really poor. I see 4 ghost images shifted. For better understanding I've attached the source image (small_world_b1.tif) and the result of bilinear resampling (but I get similar weird visual effects with cubic, cubic spline or lanczos) gdalwarp -rb small_world_b1.tif out_bilinear.tif Best regards, Even small_world_b1.tifout_bilinear.tif ___ 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
[gdal-dev] Re: Performance improvment for gdal_retile
Le samedi 18 décembre 2010 14:31:21, christian.muel...@nvoe.at a écrit : Some last comment about the test case, the current source checks test_gdal_retile_2() ds.GetRasterBand(4).Checksum() != 35 ds.GetRasterBand(4).Checksum() != 35 If I run this on a Linux Intel 32 bit configuration, it has to be ds.GetRasterBand(4).Checksum() != 283 ds.GetRasterBand(4).Checksum() != 122 Doing the same on a Linux AMD 64 Bit configuration, the values should be ds.GetRasterBand(4).Checksum() != 283 ds.GetRasterBand(4).Checksum() != 126 It seems that the cecksum is dependent on the platform. Is this desirable ? Could this cause some headaches later ? Yes, this is a bit annoying. I guess this is related to some compiler difference that impacts numerical precision with the bilinear resampling. What is your OS and compiler versions ? Do you compile in debug or optimized mode ? Do you use your script against GDAL trunk, or do you use it against GDAL 1.7 ? 35 works for me on Ubuntu 10.04 64bits, and it also works on all Windows builds of Tamas (http://vbkto.dyndns.org/sdk/) that test 7 combinations of 32/64 bit and MSVC 1310, 1400, 1500 and 1600. Cheers Christian This message was sent using IMP, the Internet Messaging Program. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Performance improvment for gdal_retile
Ah, things get complicated :-(. I am working on openSUSE 11.3, 32 Bit and Ubuntu 10.10 64 Bit. Additionally, I have SUSE Linux Enterprise on IBM pSeries and IBM zSeries (Mainframe). Some times I even use gdal on AIX. I compile against gdal 1.7, no debug mode. The important fact is that your builds work. What about checking the check sum against a list of possible values ? I have developed some test cases for my own and thought about integrating them into test_gdal_retile.py. Unfortunately this is not be possible if I use checksums because I cannot produce the correct numbers. For the moment, we can leave it as it is. Christian Quoting Even Rouault even.roua...@mines-paris.org: Le samedi 18 décembre 2010 14:31:21, christian.muel...@nvoe.at a écrit : Some last comment about the test case, the current source checks test_gdal_retile_2() ds.GetRasterBand(4).Checksum() != 35 ds.GetRasterBand(4).Checksum() != 35 If I run this on a Linux Intel 32 bit configuration, it has to be ds.GetRasterBand(4).Checksum() != 283 ds.GetRasterBand(4).Checksum() != 122 Doing the same on a Linux AMD 64 Bit configuration, the values should be ds.GetRasterBand(4).Checksum() != 283 ds.GetRasterBand(4).Checksum() != 126 It seems that the cecksum is dependent on the platform. Is this desirable ? Could this cause some headaches later ? Yes, this is a bit annoying. I guess this is related to some compiler difference that impacts numerical precision with the bilinear resampling. What is your OS and compiler versions ? Do you compile in debug or optimized mode ? Do you use your script against GDAL trunk, or do you use it against GDAL 1.7 ? 35 works for me on Ubuntu 10.04 64bits, and it also works on all Windows builds of Tamas (http://vbkto.dyndns.org/sdk/) that test 7 combinations of 32/64 bit and MSVC 1310, 1400, 1500 and 1600. Cheers Christian This message was sent using IMP, the Internet Messaging Program. This message was sent using IMP, the Internet Messaging Program. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] An issue about using GDALWARP to do the NTv2transformation
http://osgeo-org.1803224.n2.nabble.com/file/n5848200/gdalwarp_problem1.doc gdalwarp_problem1.doc Hi Uwe, I have tried your suggestion on the same raster file with a modified +x_0=50 parameter in the command line (as seen in the attached doc). I could see the major difference:there is still one error message left. When I tried on another raster file with the same modified parameter, I have got much less error messages than before. However, is it still possible that my raster data are outside the area of the grid shift file? All the raster data I was trying to transform are GK (DHDN) zone 4, which false easting value is 450. This was why I used +x_0=450 instead of +x_0=50 in the command line. As I am getting to know all these georeference settings at the moment, can you tell me why you suggested the modified parameter and what you meant about raster data lacks the Gauss-Krueger meridian prefix? Thanks for your help again. Best Regards, Heng -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/An-issue-about-using-GDALWARP-to-do-the-NTv2-transformation-tp5838904p5848200.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Kirk McKelvey
+1 Tamas 2010/12/18 Frank Warmerdam warmer...@pobox.com Folks, Motion: Extend Commit Priveledges for Kirk McKelvey. Kirk is a software developer at Lizardtech and has been workin with GDAL for a number of years. He has proposed some patches to upgrade to version 8 of the MrSID SDK and to fix up a few other things: http://trac.osgeo.org/gdal/attachment/ticket/3839/mrsid-v8.patch He has offered to become a commiter in order to better maintain the MrSID driver in GDAL on an ongoing basis and I'd love that. He might also assist with other fixes of value to Lizardtech. I'll start the motion with: +1 Frank -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdamhttp://pobox.com/%7Ewarmerdam 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
