[Gdal-dev] Problems translating BSB files

[Frank Warmerdam]

On 1/19/06, Eric Dönges <eric.doenges at gmx.net> wrote:
> Ed, I think the problem is the following code in bsb_read.c (please
> note that this is
> from a fairly old version of GDAL, since I have extensively rewritten
> BSB support -
> unfortunately, I cannot share this code with the world at large
> because the necessary
> information to do the rewrite was obtained under NDA from MapTech -
> so this might not be
> exactly like this in recent GDAL code):
>
>      {
>          int    nSkipped = 0;
>
>          while( nSkipped < 100
>                && (BSBGetc( fp, bNO1 ) != 0x1A || BSBGetc( fp,
> bNO1 ) != 0x00) )
>              nSkipped++;
>
>          if( nSkipped == 100 )
>          {
>              BSBClose( psInfo );
>              CPLError( CE_Failure, CPLE_AppDefined,
>                        "Failed to find compressed data segment of BSB
> file." );
>              return NULL;
>          }
>      }
>
>
> The file in question (83116_1.KAP) look like this in the hexdump:
>
> 00000f50  32 34 33 31 0d 0a 1a 1a  00 33 01 a0 9e 04 00 02  |
> 2431.....3......|
>
> Note the two 0x1a directly following each other. So what happens is
> that in the while
> loop above, a BSBGetc is executed, which fetches 0x1a, which means
> the second BSBGetc
> in the || clause is executed, which also fetches a 0x1a. Since this
> is not a zero,
> the test is true and nSkipped is incremented. In the next run through
> the loop,
> BSBGetc gets a zero, and then we never find the 0x1a 0x00 sequence.

Eric,

I thought of that, and modified a local copy of bsb_read.c to identify
the 0x1a 0x00 properly.  Next I discovered that the next byte, which
should be the number of bits (often 0x04 or 0x03) was crazy (0x33).
I took a bit of a jump-of-intuition and guessed that 0x33 (ASCII '3')
should have been binary 0x03 and tried to operate on that basis.
But this still produced a corrupt image, even though it did get
a bit further.

It was at this point that I gave up, under the assumption that there
were significant things I was missing.

Good work identifying the 0x1A 0x00 issue though!  You are
a binary file dumping, reverse engineering fellow after my own
heart.

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