variation on label to image pointer (PDS)

[thare]

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

[warmerdam]

I have implemented this in trunk (r17784) and 1.6 branch (r17785).

I have also added a test to the test suite in trunk (r17783) for this detached with offset image. The fix should be in GDAL 1.6.3, and 1.7.0.

Let me know if you run into more problems.

PS. It should work for IMAGE = and SPECTRAL_QUBE =.

[gaige]

The implementation to fix this is actually flawed based on both experimentation and the documentation.

Documentation for PDS (​http://pds.jpl.nasa.gov/documents/sr/Chapter05.pdf) states that the construct: ^{IMAGE = ("foo.img",2) means begin with the second record, based on the record size of the image} IMAGE = ("foo.img", 2<BYTES>) would begin with the second byte, but it is not a skip two bytes, it is use the second byte in the file.

I ran across this because I have some PDS files from NASA pertaining to mars that do not read correctly due to having ^{IMAGE = ("foo.img",1) which is actually the equivalent of:} IMAGE = "foo.img"

However, with the current implementation, it fails twice in the 1.6.3 branch. First, it results in no file being read because the implementation of GetKeywordSub removes the surrounding quotation marks, thus causing the next test (the test which determines it is referencing an external file) to fail.

Second, it results in the file being read after skipping 1 byte into the file.

I have patched this and am looking for a real-world test set, but I do have a contrived one right now using a short (524K) image file and a pair of .lbl files.

[gaige]

Oops. Should have said 1.6.4 branch, not 1.6.3.

[gaige]

I found a real test data set, which resulted in finding another bug and adding another interpretation. I'll post my changes in a new ticket.

[gaige]

Ticket #3355 is my diffs against 1.6.3

[Jukka Rahkonen]

Who knows if #3355 did solve also this issue?

[Jukka Rahkonen]

The comments of ticket #3355 tell that among other fixes it also solves what this ticket is about:

The 3 image pointer formats IMAGE = ("blah.img") , IMAGE= ("blah.img",1) and IMAGE = ("blah.img", 1 <BYTES> )

Closing as fixed.