id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
3177	variation on label to image pointer (PDS)	thare	warmerdam	"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)

ftp://pdsimage2.wr.usgs.gov/pub/pigpen/.temp/DTEEC_008669_1705_009025_1705_A01.zip

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.

thanks,
Trent"	defect	reopened	high	1.8.1	GDAL_Raster	1.6.1	normal		PDS detached label