Re: [gdal-dev] ECW JPEG2000 SDK v5.0 now available
Bummer, still no OS X support. On Jul 14, 2013, at 10:35 PM, Tweedie, Chris wrote: Hi list, Due to overwhelming interest from GDAL-ers I have cross posted the announcement here. For general SDK questions please post to http://geospatial.intergraph.com/Community/forums/27.aspx SDK v5.0 is now available for download @ http://geospatial.intergraph.com/products/other/ecw/ERDASECWJPEG2000SDK/Downloads.aspx Highlights include, . Linux platform support . Visual Studio 2012 support (VC110) . Removed TBB dependency . Static and dynamic library support . ECW v3 format - uint16 support - null blocks to optimally store and compress imagery with vast no-data or null areas - improved metadata support, statistics, histogram, RPC native storage . Improved image quality for ECW files (decoder only) . Vast improvements to the JPEG2000 decoder in terms of performance and compatibility . Significant encoding performance improvements . Full unicode support . Improved examples for encoding and decoding . Now a single unified library, NCSEcw (.dll / .so) We are sure it was worth the wait, but let me know if you disagree :-) Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ECW JPEG2000 SDK v5.0 now available
Le 15/07/2013 15:26, William Kyngesburye a écrit : Bummer, still no OS X support. and no Linux support for ARM. SDK 3.3 is still the best option. Intergraph is killing the ECW format. Jean-Claude ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Working with NTF files
No (except that I left this option as the final attempt of many tests -- working with some 1GB images here, so it took me hours... :D). Your confirmation, though, is highly useful! Sometimes to avoid materializing large intermediate datasets on disk, a VRT can be used. I'm not sure if this would be useful in your case. On the GDAL side we often have special info in trac wiki pages under the BuildHints page, but in this case the issues are more usage rather than building so there is no obvious place for user contributions. The format pages for NITF do have quite a bit of info. It is (I think) the only driver with an advanced page. However, there are many kinds of NITF files and thus usage patterns that are an issue so it isn't clear how to handle that in the user docs. I and others have put GDAL usage notes here, http://trac.osgeo.org/gdal/wiki/CodeSnippets Best Regards, Eli ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr bug with dwg file
Le lundi 15 juillet 2013 04:23:30, Xian Chen/陈羡 a écrit : Hi Even, Thanks for your quick response. I tested your patch on OGR2OGR. All right, the application does not crash now. Does that mean with this patch we don't need to call OGRCleanupAll() mandatorily? Well, OGRCleanupAll() is advised to be called to clean up things properly (mainly if you use a memory debugger, to avoid GDAL memory to be reported as leaking). What is really compulsory is to destroy datasources so that they get properly closed. I am asking this question because we have our own Windows application developed based on GDAL/OGR. If we include OGR_DWG.dll the application will always crash when exiting (the application called OGRCleanupAll() explicitly). Hum, this is not supposed to happen. So my hypothesis was not completely right (neither wrong). It seems that it is the destructor of the DWG driver that causes problem, be it called explicitely or implicitely... I'm not in position to debug this, so it would be interesting to know if every user of the DWG driver encounters this, or if it might not come from the way how your GDAL binaries have been built. Best Regards, Xian Le jeudi 11 juillet 2013 09:33:36, Xian Chen a écrit : Hi all, Finally I've got a chance to report something after one-month silence as a newcomer in the community. After running ogr2ogr (on Windows 7) to convert a dwg file into shape files, I received an error message as follows: /Warning 6: Normalized/laundered field name: 'ExtendedEntity' to 'ExtendedEn' Warning 6: Normalized/laundered field name: 'EntityHandle' to 'EntityHand' ERROR 1: Attempt to write non-linestring (POINT) geometry to ARC type shapefile. ERROR 1: Terminating translation prematurely after failed translation of layer entities (use -skipfailures to skip errors)/ And then the application exited abnormally. I read the source code and found that the last error message was produced by an error from TranslateLayer(). The application terminated there without calling OGRCleanupAll() Therefore I tested reading dwg file on OGR. My conclusion is that OGRCleanupAll() has to be called explicitly before termination of the whole application, otherwise an abnormal termination (due to stack overflow??) will occur. Hi Xian, Interesting. Yes calling OGRCleanupAll() is a best practice, and probably that even the error code paths in the utilities should call it, but it shouldn't be compulsory to call it. Looking at the code of the DWG driver, I see that the driver has indeed code in its destructor to call the odUninitialize() function. When you call OGRCleanupAll() then this code is called. But GDAL has also a DLL clean-up code that will call OGRCleanupAll(). I suspect that in that case, some C++ automatic objects normally cleaned by odUninitialize() have already been destroyed, and at the time odUninitialize() is called, it will access them at the time where they are no longer available. Hence the crash. Being not in position to test it myself, in order to confirm my above guess, could you revert your changes in ogr2ogr.cpp and test the attached patch (based on GDAL trunk) ? Best regards, Even -- View this message in context: http://osgeo-org.1560.x6.nabble.com/ogr2ogr-bug-with-dwg-file-tp5065611.h t ml 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 -- Geospatial professional services http://even.rouault.free.fr/services.html -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Can't get colour table for GeoTIFF
Hi! I'm using the code below as part of a routine to warp images. For most images it works fine. However, for one of my users, their images are being converted from full colour to black and white which is not supposed to happen. I've narrowed down the issue to the code below where 'hCT' remains NULL. An example of one such source image can be downloaded at: https://dl.dropboxusercontent.com/u/12436846/jrc_21.tiff I guess I must be doing something wrong in my code, but can't figure it out. Could somebody please help me to understand how to do this correctly? Ie, how to I get the colour table from the image linked to above, and set that colour table for my destination image? Cheers, Nik. GDALColorTableH hCT = GDALGetRasterColorTable( GDALGetRasterBand(hSrcDS,1) ); if ( hCT == NULL ) NSLog(@Failed to get colour table.); else GDALSetRasterColorTable( GDALGetRasterBand(hDstDS,1), hCT ); ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Can't get colour table for GeoTIFF
Nike, The gdalinfo report on the file is as follows. It is an RGBA file - that is it has four bands which are red, green, blue and alpha. It appears you are configured to only work with single band pseudo-colored images (images with a palette). I suppose you will need to generalize your code for this case. gdalinfo jrc_21.tiff Driver: GTiff/GeoTIFF Files: jrc_21.tiff Size is 1009, 753 Coordinate System is: PROJCS[WGS 84 / UTM zone 32N, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.257223563, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,32632]] Origin = (470363.73489981280,5073657.70839886751) Pixel Size = (2.060455896927651,-2.061088977423639) Metadata: AREA_OR_POINT=Area TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) TIFFTAG_XRESOLUTION=96 TIFFTAG_YRESOLUTION=96 Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 470363.735, 5073657.708) ( 8d37' 6.69E, 45d48'57.04N) Lower Left ( 470363.735, 5072105.708) ( 8d37' 7.04E, 45d48' 6.76N) Upper Right ( 472442.735, 5073657.708) ( 8d38'43.03E, 45d48'57.35N) Lower Right ( 472442.735, 5072105.708) ( 8d38'43.35E, 45d48' 7.07N) Center ( 471403.235, 5072881.708) ( 8d37'55.03E, 45d48'32.06N) Band 1 Block=1009x2 Type=Byte, ColorInterp=Red NoData Value=0 Band 2 Block=1009x2 Type=Byte, ColorInterp=Green NoData Value=0 Band 3 Block=1009x2 Type=Byte, ColorInterp=Blue NoData Value=0 Band 4 Block=1009x2 Type=Byte, ColorInterp=Alpha NoData Value=0 On Mon, Jul 15, 2013 at 4:07 PM, Nik Sands nix...@nixanz.com wrote: Hi! I'm using the code below as part of a routine to warp images. For most images it works fine. However, for one of my users, their images are being converted from full colour to black and white which is not supposed to happen. I've narrowed down the issue to the code below where 'hCT' remains NULL. An example of one such source image can be downloaded at: https://dl.dropboxusercontent.com/u/12436846/jrc_21.tiff I guess I must be doing something wrong in my code, but can't figure it out. Could somebody please help me to understand how to do this correctly? Ie, how to I get the colour table from the image linked to above, and set that colour table for my destination image? Cheers, Nik. GDALColorTableH hCT = GDALGetRasterColorTable( GDALGetRasterBand(hSrcDS,1) ); if ( hCT == NULL ) NSLog(@Failed to get colour table.); else GDALSetRasterColorTable( GDALGetRasterBand(hDstDS,1), hCT ); ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- 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 Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ECW JPEG2000 SDK v5.0 now available
Chris, I tried it out and it looks pretty good. I appreciate that the various compiler warnings I saw including the sdk include files in the beta are now all fixed! Even, I see the ecw_29 test case your introduced in r26176 (for #4822) now fails. The current results seem to supersample in a different way that GDAL normally would - an off by a half issue that think is a reasonable interpretation of how to supersample. Should the test be modified with a different case for ECW 5? Or perhaps the test is just too fragile to be worthwhile? Best regards, Frank On Sun, Jul 14, 2013 at 8:35 PM, Tweedie, Chris chris.twee...@intergraph.com wrote: Hi list, Due to overwhelming interest from GDAL-ers I have cross posted the announcement here. For general SDK questions please post to http://geospatial.intergraph.com/Community/forums/27.aspx SDK v5.0 is now available for download @ http://geospatial.intergraph.com/products/other/ecw/ERDASECWJPEG2000SDK/Downloads.aspx Highlights include, . Linux platform support . Visual Studio 2012 support (VC110) . Removed TBB dependency . Static and dynamic library support . ECW v3 format - uint16 support - null blocks to optimally store and compress imagery with vast no-data or null areas - improved metadata support, statistics, histogram, RPC native storage . Improved image quality for ECW files (decoder only) . Vast improvements to the JPEG2000 decoder in terms of performance and compatibility . Significant encoding performance improvements . Full unicode support . Improved examples for encoding and decoding . Now a single unified library, NCSEcw (.dll / .so) We are sure it was worth the wait, but let me know if you disagree :-) Chris ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- 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 Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
