PDS "v3" detached label calculates wrong LineOff

thareUSGS commented 6 years ago

Expected behavior and actual behavior.

Fails to open/convert PDS label. It is pointing into a FITS file (but it the FITS should be treated as raw). The PDS3 label should describe it for opening.

Using environment variable "CPL_DEBUG=ON", I can see the listed "rawRasterBand" is incorrectly setting to LineOff=8640 instead of LineOff=6000.

I was originally blaming the skipbytes but that looks good.

I think the line might be: https://github.com/OSGeo/gdal/blob/04296c631cf9d73cb8f20ed5cb6ecd519b3b9bd6/gdal/frmts/pds/pdsdataset.cpp#L1035

walking though the code, it seems all should be working and nLineOffset would correctly equal 6000...?

I'm not sure how LineOff is getting calculated to 8640? That is 2880 * 3 (but perhaps just happenstance).

I don't see anything in the label formatting to throw this off, so I am at a loss to figure it out. I am not worried about other aspects of this label (like no projection) -- just the pixel read.

Steps to reproduce the problem.

test file: https://www.dropbox.com/s/f80t7a94v7om0at/038.zip?dl=0

> gdal_translate map_000_038.lbl tst.tif   ## w/ "CPL_DEBUG=ON"
GNM: GNMRegisterAllInternal
GNM: RegisterGNMFile
GNM: RegisterGNMdatabase
GDALRaw: RawRasterBand(00000288D39EE910,1,0000000000000000,
              Off=2880,PixOff=1,LineOff=8640,Byte,1)
PDS: using projection

PDS: Dataset projection  is not supported. Continuing...
GDAL: GDALOpen(map_000_038.lbl, this=00000288D39EE910) succeeds as PDS.
Input file size is 6000, 3000
GDAL: Using GTiff driver
0GDAL: GDAL_CACHEMAX = 613 MB
GDAL: GDALDatasetCopyWholeRaster(): 6000*1666 swaths, bInterleave=0
...10...20...30...40...50...ERROR 3: Failed to read scanline 2083.
ERROR 1: map_000_038.lbl, band 1: IReadBlock failed at X offset 0, Y offset 2083: Failed to read scanline 2083.
GDAL: GDALClose(map_000_038.lbl, this=00000288D39EE910)
GDAL: In GDALDestroy - unloading GDAL shared library.

Note: The provide VRT in the download, just shows how the FITS should be opened (and look).

Operating system

Windows 10 and CentOS Linux release 7.2.1511

GDAL version and provenance

2.3.1 version from conda-forge

rouault commented 6 years ago

@thareUSGS Looking at the file and code (I'm not familiar with the PDS3 specs, so I'm not sure if it is the driver or the file that is faulty), I see the main cause for the error: the declared record size is 2880 bytes, but this is only valid for the header, and not the imagery part, whereas the code assume thats the record size applies to all parts of a file. And yes nLineOffset = 8640 comes from divising 6000 by 2880, rounding up the result from 2.08... to 3, and then multipying back by 2880.

I've managed to get the driver to read the label, by changing

RECORD_BYTES               = 2880

to

RECORD_BYTES               = 6000

and

^IMAGE                     = ("MAP_000_038.FIT",2)

to

^IMAGE                     = ("MAP_000_038.FIT",2880 <BYTES>)

thareUSGS commented 6 years ago

That helps. I need to research if the original code might be wrong (or if the label is wrong). In general, the current method to define nLineOffset seems to work fine for most files. The odd occurance here is that FITS files are locked at a record length of 2880 bytes. https://www.eso.org/sci/software/esomidas/doc/user/98NOV/vola/node111.html

hold for more.

OSGeo / gdal