| | 720 | } |
|---|
| | 721 | } |
|---|
| | 722 | /* This is a fix for a problem with rpf/cjga/cjgaz01/0105f033.ja1 and */ |
|---|
| | 723 | /* rpf/cjga/cjgaz03/0034t0b3.ja3 CADRG products (bug 1754). */ |
|---|
| | 724 | /* These products have the strange particularity that their block start table begins */ |
|---|
| | 725 | /* one byte after its theoretical beginning, for an unknown reason */ |
|---|
| | 726 | /* We detect this situation when the block start offset is not a multiple of 6144 */ |
|---|
| | 727 | /* Hopefully there's something in the NITF/CADRG standard that can account for it, */ |
|---|
| | 728 | /* but I've not found it */ |
|---|
| | 729 | if (isM4 && i != nBlockCount) |
|---|
| | 730 | { |
|---|
| | 731 | CPLError( CE_Warning, CPLE_AppDefined, |
|---|
| | 732 | "Block start for block %d is wrong. Retrying with one extra byte shift...", i); |
|---|
| | 733 | VSIFSeekL( psFile->fp, psSegInfo->nSegmentStart + |
|---|
| | 734 | 4 + /* nIMDATOFF */ |
|---|
| | 735 | 2 + /* nBMRLNTH */ |
|---|
| | 736 | 2 + /* nTMRLNTH */ |
|---|
| | 737 | 2 + /* nTPXCDLNTH */ |
|---|
| | 738 | (nTPXCDLNTH+7)/8 + |
|---|
| | 739 | 1, /* MAGIC here ! One byte shift... */ |
|---|
| | 740 | SEEK_SET ); |
|---|
| | 741 | VSIFReadL( psImage->panBlockStart, 4, nBlockCount, psFile->fp ); |
|---|
| | 742 | for( i=0; i < nBlockCount; i++ ) |
|---|
| | 743 | { |
|---|
| | 744 | CPL_MSBPTR32( psImage->panBlockStart + i ); |
|---|
| | 745 | if( psImage->panBlockStart[i] != 0xffffffff ) |
|---|
| | 746 | { |
|---|
| | 747 | if ((psImage->panBlockStart[i] % 6144) != 0) |
|---|
| | 748 | { |
|---|
| | 749 | CPLError( CE_Warning, CPLE_AppDefined, |
|---|
| | 750 | "Block start for block %d is still wrong. Display will be wrong.", i ); |
|---|
| | 751 | break; |
|---|
| | 752 | } |
|---|
| | 753 | psImage->panBlockStart[i] |
|---|
| | 754 | += psSegInfo->nSegmentStart + nIMDATOFF; |
|---|
| | 755 | } |
|---|
| | 756 | } |
|---|