[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