[Gdal-dev] Warping an ecw

[SteveC]

Hi

I'm trying to transform an ecw but always get errors. Any help/pointers
appreciated.

I get

$ gdalwarp -tr 0.001 0.001 -t_srs "epsg:4326" -of GTiff foo.ecw foo.tiff
Creating output file that is 784P x 648L.
:0.ERROR 1: NCScbmReadViewLineBIL failed.

$ gdalwarp -t_srs "epsg:4326" -te 0 50 10 60 -ts 30 30 -of GTiff foo.ecw foo.tiff
Creating output file that is 30P x 30L.
:0..10..20...33..40...50...61..ERROR 1: NCScbmReadViewLineBIL failed.

$ gdal-config --version
1.3.1

$ uname -a
Linux fang 2.6.13 #2 Mon Oct 24 23:36:45 BST 2005 i686 GNU/Linux

$ proj --version
Rel. 4.4.9, 29 Oct 2004

$ gdalinfo foo.ecw
Driver: ECW/ERMapper Compressed Wavelets
Size is 262000, 340500
Coordinate System is:
PROJCS["TMOSGB",
GEOGCS["ORDNANCE SURVEY 1936",
DATUM["OSGB36",
SPHEROID["AIRY",6377563.396,299.3249646]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",49],
PARAMETER["central_meridian",-1.999999999999966],
PARAMETER["scale_factor",0.999601272],
PARAMETER["false_easting",-100000],
PARAMETER["false_northing",400000],
UNIT["Meter",1]]
Origin = (132000.000000,691001.000000)
Pixel Size = (2.00000000,-2.00000000)
Corner Coordinates:
Upper Left ( 132000.000, 691001.000) ( 1d20'53.45"E, 51d34'10.52"N)
Lower Left ( 132000.000, 10001.000) ( 0d58'2.29"E, 45d27'6.44"N)
Upper Right ( 656000.000, 691001.000) ( 8d48'56.20"E, 51d 6'54.75"N)
Lower Right ( 656000.000, 10001.000) ( 7d36'26.35"E, 45d 5'3.75"N)
Center ( 394000.000, 350501.000) ( 4d40'17.19"E, 48d21'39.14"N)
Band 1 Block=262000x1 Type=Byte, ColorInterp=Red
Overviews: arbitrary
Band 2 Block=262000x1 Type=Byte, ColorInterp=Green
Overviews: arbitrary
Band 3 Block=262000x1 Type=Byte, ColorInterp=Blue
Overviews: arbitrary

[Frank Warmerdam]

Post by SteveC
Hi
I'm trying to transform an ecw but always get errors. Any help/pointers
appreciated.
I get
$ gdalwarp -tr 0.001 0.001 -t_srs "epsg:4326" -of GTiff foo.ecw foo.tiff
Creating output file that is 784P x 648L.
:0.ERROR 1: NCScbmReadViewLineBIL failed.
$ gdalwarp -t_srs "epsg:4326" -te 0 50 10 60 -ts 30 30 -of GTiff foo.ecw foo.tiff
Creating output file that is 30P x 30L.
:0..10..20...33..40...50...61..ERROR 1: NCScbmReadViewLineBIL failed.
$ gdal-config --version
1.3.1

Steve,

I'm not sure what is going wrong. What version of the ECW SDK are
you using? I will warn you that even if this works, it will be very slow
since the warper will always load the source chunks at full resolution.
I gather you are wanting to use gdalwarp to dramatically downsample
the data?

You might want to try something like "gdalinfo -mm foo.ecw".
This should force one read pass over the whole file computing
the min and max. If this fails, then we can suspect there is
something wrong with the file, or with the ECW SDK in
simple access situations. If that works fine, then it may be
something more complex.

I have submitted a bug report to ERMapper where I had crashes in
the ECW SDK when doing many small windowed reads on a large
file. I haven't heard back if they were able to reproduce it. You
might be running into something similar.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, ***@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent

[David McKenzie]

Hi Folks,

Post by Frank Warmerdam
....
I have submitted a bug report to ERMapper where I had crashes in
the ECW SDK when doing many small windowed reads on a large
file. I haven't heard back if they were able to reproduce it. You
might be running into something similar.
...

I had been intending to report a similar problem I encountered with ECW SDK
v3.3 RC1 (and possibly an earlier version). GDAL's RasterIO() fails on the
second band when reading multiple bands in succession -- but only if the
window width is *larger* than 4000 pixels. I found that I could resolve the
problem by initializing a variable, m_nNextLine, in function
CNCSJP2FileView::SetView(). In file NCSJP2FileView.cpp (line 940) you might
try replacing

if (m_pECWFileView) {
CNCSError Error;

with

if (m_pECWFileView) {
m_nNextLine = 0;
CNCSError Error;

Without this fix, CNCSJP2FileView::ReadLineBIL() inevitably returns
NCSECW_READ_FAILED with at least two large images I've experimented with.

--David

[Tom Lynch]

On 11/15/05, David McKenzie <***@austin.rr.com> wrote:
<snip>

Post by David McKenzie
I had been intending to report a similar problem I encountered with ECW SDK
v3.3 RC1 (and possibly an earlier version). GDAL's RasterIO() fails on the
second band when reading multiple bands in succession -- but only if the
window width is *larger* than 4000 pixels. I found that I could resolve the
problem by initializing a variable, m_nNextLine, in function
CNCSJP2FileView::SetView(). In file NCSJP2FileView.cpp (line 940) you might
try replacing

<snip>

Hi David, Frank and Steve,

I've made a note of the problem you're reporting and your suggested
patch David. It looks as if it may be related to the 4000x4000
limitation imposed on cachable view size. I will attempt to reproduce
it and add it to the open bug list if I can.

David, if you can forward me additional information about your
operating environment it would be much appreciated.

Incidentally I was able to repeat the problem that Frank found and
have been looking for a fix, but I don't believe this is a symptom of
the same issue.

cheers

--
Tom Lynch
Development, ER Mapper
Phone: [phone]
Fax: [phone]
Email: ***@ermapper.com
Web: http://www.ermapper.com
Forums: http://forum.ermapper.com

[David McKenzie]

Hi Tom,

Post by Tom Lynch
I've made a note of the problem you're reporting and your suggested
patch David. It looks as if it may be related to the 4000x4000
limitation imposed on cachable view size. I will attempt to reproduce
it and add it to the open bug list if I can.
David, if you can forward me additional information about your
operating environment it would be much appreciated.
...

Basically I'm using the project file, libecwj2_win32_net_static.vcproj
supplied with the SDK, to create libecwj2S.lib that I statically link to my
Windows-based viewer program. The library is accessed via the GDAL (approx
v1.3.1) function, ECWRasterBand::IRasterIO(), in ecwdataset.cpp. When
reading a band, CNCSJP2FileView::SetView() is called once (with the width
being relevant here) followed by successive calls to ReadLineBIL() to read
pixel rows. You'll see that only when width>4000 (m_bTiledView==true) is the
variable m_nNextLine incremented for each row. The problem is that when
ReadLineBIL() is first called for the *second* band, m_nNextLine is not zero
and a check of its range at the start of the function fails.

This is surely a problem introduced in the latest SDK version since it would
apparently break many programs that process large chunks of data, including
utilities like gdal_translate and gdalwarp. In case it helps to see what's
affected, I've uploaded two small ECW files, one 3386x132x3 and the other
4120x132x3:

http://www.utexas.edu/tmm/sponsored_sites/tss/Walls/temp/test_narrow.ecw
http://www.utexas.edu/tmm/sponsored_sites/tss/Walls/temp/test_wide.ecw

Thanks for the quick reply.

--David

[SteveC]

Post by Frank Warmerdam

Post by SteveC
Hi
I'm trying to transform an ecw but always get errors. Any help/pointers
appreciated.
I get
$ gdalwarp -tr 0.001 0.001 -t_srs "epsg:4326" -of GTiff foo.ecw foo.tiff
Creating output file that is 784P x 648L.
:0.ERROR 1: NCScbmReadViewLineBIL failed.
$ gdalwarp -t_srs "epsg:4326" -te 0 50 10 60 -ts 30 30 -of GTiff foo.ecw foo.tiff
Creating output file that is 30P x 30L.
:0..10..20...33..40...50...61..ERROR 1: NCScbmReadViewLineBIL failed.
$ gdal-config --version
1.3.1

Steve,
I'm not sure what is going wrong. What version of the ECW SDK are
you using? I will warn you that even if this works, it will be very slow

libecwj2-3.3

That cool?

Post by Frank Warmerdam
since the warper will always load the source chunks at full resolution.
I gather you are wanting to use gdalwarp to dramatically downsample
the data?
You might want to try something like "gdalinfo -mm foo.ecw".
This should force one read pass over the whole file computing
the min and max. If this fails, then we can suspect there is
something wrong with the file, or with the ECW SDK in
simple access situations. If that works fine, then it may be
something more complex.

It failesd :-(

Lots of lines like

ERROR 1: TryWinRasterIO() failed for blocked scanline.
ERROR 1: IReadBlock failed at X offset 0, Y offset 25043

Post by Frank Warmerdam
I have submitted a bug report to ERMapper where I had crashes in
the ECW SDK when doing many small windowed reads on a large
file. I haven't heard back if they were able to reproduce it. You
might be running into something similar.

Oh dear. I'd hoped this would be easy :-)

have fun,

SteveC ***@asklater.com http://www.asklater.com/steve/