Oddly ordered ecw translation fails

[warmerdam]

A translation of RGBImage.ecw to GeoTIFF fails if
the data is requested in band interleaved order.  That
is if a RasterIO() is made for the 1st line of 1st band,
then 1st line of second band, 1st line of 3rd band, 
2nd line of 1st band, etc.

I was able to boil this down to a problem reproducable
with just the attached small program that only uses
the ecw sdk.

Notes:
 o input file is the "standard" RGBImage.ecw (4320x2160
   world image).  

 o Roughly the last 50 scanlines or so are corrupted in
   the output image. 

 o The sample program writes out a simple raw raster, BIL,
   4320 x 160 (just the last 160 lines of the input file). 

 o The sample code sets a new view for each request.  I know
   this is inefficient, but it should work.

 o The sample code actually sets the view for all the remainder
   of the image from that scanline on, but only ever reads the
   first scanline of the view.  If I change the SetView() to only
   set a view for one scanline things work.

 o The problem was tested on win32 with libecwj2-3.3 RC1.

[warmerdam]

Small sample ecw sdk based program demonstrating bug

[warmerdam]

View of output image fragment, showing corruption on bottom half.

[tom.lynch@…]

I'm fiddling around with this trying to repeat it - the sample program is a
little weird, setting views of different sizes every time it reads a line (it's
not the number of views set that bothers me, but the fact that they're always of
a different aspect).  Nonetheless it looks like it should work.

[warmerdam]

Tom, 

In case you are interested, the reason it does this is to mirror how GDAL
does stuff.  In GDAL if you ask for a single scanline the library tries
to guess that you will be asking for more scanlines later and sets up a view
at the requested resolution for the rest of the image.  However in some
access patterns (such as BIL requests) the next request is not the next line
in the window, and the window needs to be reset. 

[tom.lynch@…]

Thanks Frank - I've repeated the issue now.  The sample code makes plenty of
sense in light of that comment as well.

[tom.lynch@…]

Frank,

This issue was a regression in 3.3RC1 caused by changes to the SetView logic. 
The SDK now allows non-tiled views of any width provided they are less high than
the standard strip height of 64.  Views of a greater height use tiled view logic.

The lookahead views being created by GDAL and the sample program were always
tiled up until such time as the file position reached the end of the last 64
pixel strip.  At this stage the logic was not setting the status of a flag
indicating whether or not to use the tiled view logic back to false, meaning
that bogus data was acquired from the file because non-tiled SetView metadata
was being used to read data using the tiled logic.

I will attach a patch file in a moment showing the changes needed to set the
value of the flag correctly for both the ECW and JP2 cases.  The changes are in
$SDK/Source/C/NCSEcw/NCSJP2/NCSJP2FileView.cpp.

The patch is not yet thoroughly tested (although the problem as repeated using
your sample code no longer occurs) but obviously feedback on whether it appears
to fix the problem at your end as well is appreciated :-)

[tom.lynch@…]

Patch to NCSJP2FileView.cpp