Ticket #3177 (reopened defect)
variation on label to image pointer (PDS)
|Reported by:||thare||Owned by:||warmerdam|
|Severity:||normal||Keywords:||PDS detached label|
Description (last modified by warmerdam) (diff)
We have uncovered a defect for the PDS image type when using detached labels. Unfortunately, it was not written into the original PDS reader as the only cases that were accounted were:
1. // ^IMAGE = 3 2. // ^IMAGE = "GLOBAL_ALBEDO_8PPD.IMG" 3. // ^IMAGE = "MEGT90N000CB.IMG" 4. // ^SPECTRAL_QUBE = 5 for multi-band images
where 1 is an in-line label and the skipbyte = 3. where 2,3 points to a detached image with implied skipbyte = 0. where 4 is an in-line label and a skipbyte = 5. The "SPECTRAL_QUBE" just says it is multi-band even though there is a BANDS keyword.
so the new style that has been encounter is:
5. //^IMAGE = ("DTEEC_008669_1705_009025_1705_A01.IMG", 2)
where the label is pointing to a detached image but still requires a skipbyte of 2 into the file.
I guess we might want to account for (essentially the same thing as above).
5. //^SPECTRAL_QUBE = ("DTEEC_008669_1705_009025_1705_A01.IMG", 2)
test file (sorry so large - 500MB)
note: this image has a duplicate embedded PDS label (which is why we need the skipbytes - don't ask me why) so gdalinfo will work correctly for the *.IMG alone. It will also appear to work correctly for the *.LBL but it will use a skipbyte of 0 not 2. If you request -stats it will fail with some noise at the top.