[Gdal-dev] Warping an ecw

David McKenzie davidmck at austin.rr.com
Wed Nov 16 09:42:26 EST 2005


Hi Tom,

Tom Lynch wrote:
>
> 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 




More information about the Gdal-dev mailing list