gdal_translate crashes with libecwj2-3.3 when creating files

[Markus Neteler]

I compiled libecwj2-3.3 with ./configure ; make ; make install.

I have a 2.5GB GeoTIFF DEM which I want to convert in ECW, but

gdalinfo /geodata2_originals_raid5/pat_DTM_2008_derived_5m_UTM_WGS84.tif
Driver: GTiff/GeoTIFF
Files: /geodata2_originals_raid5/pat_DTM_2008_derived_5m_UTM_WGS84.tif
Size is 23522, 19509
Coordinate System is:
PROJCS["WGS 84 / UTM zone 32N",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
...
Origin = (612488.000000000000000,5157086.000000000000000)
Pixel Size = (5.000000000000000,-5.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  612488.000, 5157086.000) ( 10d28'3.20"E, 46d33'28.53"N)
Lower Left  (  612488.000, 5059541.000) ( 10d26'39.96"E, 45d40'49.04"N)
Upper Right (  730098.000, 5157086.000) ( 12d 0'1.22"E, 46d31'40.71"N)
Lower Right (  730098.000, 5059541.000) ( 11d57'11.27"E, 45d39'4.45"N)
Center      (  671293.000, 5108313.500) ( 11d12'59.25"E, 46d 6'24.85"N)
Band 1 Block=23522x1 Type=Float32, ColorInterp=Gray
  Overviews: 11761x9755, 5881x4878, 2941x2439, 1471x1220, 736x610, 368x305, 184x153

gdal_translate -of ECW  pat_DTM_2008_derived_5m_UTM_WGS84.tif
pat_DTM_2008_derived_5m_UTM_WGS84.ecw
Input file size is 23522, 19509
0ERROR 1: An error has occurred: Error 47 "An invalid parameter was
used"  file "" line 46995532152832

This error is a bit mysterious to me. Mateusz told me:

This error code is defined in libecwj header file NCSErrors.h, in enum NCSError:

NCS_INVALID_PARAMETER,          /**< An invalid parameter was used */

But he doesn't really know what parameter is invalid, however. I have also tried to set GDAL creation option: LARGE_OK=YES.

Then I tried JP2ECW:

gdal_translate -of JP2ECW  pat_DTM_2008_derived_5m_UTM_WGS84.tif
pat_DTM_2008_derived_5m_UTM_WGS84.jp2
Input file size is 23522, 19509
0Segmentation fault

Running gdb:

gdb gdal_translate
GNU gdb 6.6-3mdv2008.0 (Mandriva Linux release 2008.0)
...
This GDB was configured as "x86_64-mandriva-linux-gnu"...
Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) r -of JP2ECW /geodata2_originals_raid5/pat_DTM_2008_derived_5m_UTM_WGS84.tif pat_DTM_2008_derived_5m_UTM_WGS84.jp2
Starting program: /usr/local/bin/gdal_translate -of JP2ECW /geodata2_originals_raid5/pat_DTM_2008_derived_5m_UTM_WGS84.tif pat_DTM_2008_derived_5m_UTM_WGS84.jp2
[Thread debugging using libthread_db enabled]
[New Thread 47448558329728 (LWP 10666)]
Input file size is 23522, 19509
[New Thread 1082132816 (LWP 10670)]
[New Thread 1090525520 (LWP 10671)]
[New Thread 1098918224 (LWP 10672)]
[New Thread 1107310928 (LWP 10673)]
ERROR 1: Could not perform Read/Write on file
0[New Thread 1115703632 (LWP 10674)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1115703632 (LWP 10674)]
0x00002b2777dc453b in CNCSJPCResolution::SD_2D_OUTPUT4 (this=0x6feda0, nCtx=0x7fff348fbfb0, u0=0, u1=23522, nV=0,
    eType=CNCSJPCBuffer::BT_INT32) at ../C/NCSEcw/NCSJP2/NCSJPCResolution.cpp:1781
1781                    INT32 nPrevVert01 = pSrc1Down[n2n] - NCSFloorDiv(pSrc0[n2n] + pSrc2Down[n2n], 2);
gdb >

The error message "ERROR 1: Could not perform Read/Write on file" doesn't come out in non-gdb mode.

Any idea how to convert the file? I could not find file restrictions on export (nor how to compile libecwj2-3.3 in GPL mode if that exists).

thanks, Markus

[jcrepetto]

Same problem for me ! I am using GDAL 1.5.2 on Gentoo Linux x86-64. I am trying to convert a PNG file (size 350 Mb) to ECW, and it fails :

gdal_translate -of ECW  -co "LARGE_OK=YES" -co "TARGET=88" -co "DATUM=RGF93"  -co "PROJ=GEOPORTALFXX" -a_ullr 536575.974514 4858623.769228 542847.974216 4852095.769538 valbonne.png valbonne.ecw
Input file size is 12544, 13056
0ERROR 1: An error has occurred: Error 47 "An invalid parameter was used"  file "" line 140733193388032

[jcrepetto]

I have installed GDAL-1.4.2, and I got a more useful error message :

ERROR 6: ECW driver doesn't support data type UInt16. Only eight bit bands supported.

I have also tested GDAL-1.5.0, and it gave the same message as GDAL-1.5.2.

I think the problem reported by nedeler is similar, because gdalinfo reported a Float32 type on its file, which is probably not supported by the ECW driver.

Would it be possible to fix GDAL, so that it gives the same message as GDAL-1.4.2 ?

[warmerdam]

I have added pixel data type checking in ECWCreateCopy(). In non-strict mode it just forces things to Byte and provides a warning. In strict mode it errors out. The changes are in trunk (r15484) and in the 1.5 branch (r15485).

[Even Rouault]

Actually I think the above fix didn't address the original issue, which is a bug of the ECW SDK itself. I ran in it when running ecw_9 test on 64bit platform. I rediscovered the following fix that is an extract from ​http://www.kyngchaos.com/files/macosxport/libecwj2-3.3.patch

diff -ur libecwj2-3.3-clean/Source/C/NCSEcw/NCSJP2/NCSJPCResolution.cpp libecwj2-3.3-new/Source/C/NCSEcw/NCSJP2/NCSJPCResolution.cpp
--- libecwj2-3.3-clean/Source/C/NCSEcw/NCSJP2/NCSJPCResolution.cpp	2006-07-03 10:15:12.000000000 -0500
+++ libecwj2-3.3-new/Source/C/NCSEcw/NCSJP2/NCSJPCResolution.cpp	2008-12-10 08:58:47.000000000 -0600
@@ -1773,11 +1773,11 @@
 		//Step0-1 == 2State.
 		//
 
-		UINT32 n = 0;
+		INT32 n = 0;
 		nWidth = NCSCeilDiv(nWidth, 2);
 
-		UINT32 n2n = n * 2 - 2;
-			
+		INT32 n2n = n * 2 - 2;
+		
 		INT32 nPrevVert01 = pSrc1Down[n2n] - NCSFloorDiv(pSrc0[n2n] + pSrc2Down[n2n], 2);
 		INT32 nPrevVert11 = pSrc1Down[n2n+1] - NCSFloorDiv(pSrc0[n2n+1] + pSrc2Down[n2n+1], 2);
 		INT32 nPrevVert00 = pSrc0[n2n] + NCSFloorDiv(pSrc1Up[n2n] - NCSFloorDiv(pSrc2Up[n2n] + pSrc0[n2n], 2) + nPrevVert01 + 2, 4);
@@ -1788,7 +1788,7 @@
 		INT32 nVert01 = pSrc1Down[n2n] - NCSFloorDiv(pSrc0[n2n] + pSrc2Down[n2n], 2);
 		INT32 nVert00 = pSrc0[n2n] + NCSFloorDiv(pSrc1Up[n2n] - NCSFloorDiv(pSrc2Up[n2n] + pSrc0[n2n], 2) + nVert01 + 2, 4);
 
-		for(; n < nWidth; n++) {
+		for(; n < (INT32)nWidth; n++) {
 			n2n = 2 * n;
 
 			INT32 nVert11 = pSrc1Down[n2n+1] - NCSFloorDiv(pSrc0[n2n+1] + pSrc2Down[n2n+1], 2);