Open putza opened 6 years ago
@putza This is related to #75
There is a detached label and in order to open the image you need to have the label too. Download the lablel, which can also be found here, to the same directory as the N1454725799_1.IMG
file and then open the image with the label path.
I got it to work but let me know if you still have an issue with it
>>> from planetaryimage import PDS3Image
>>> imagedata = PDS3Image.open('Data/02NASA_Cassini/N1454725799_1.LBL')
>>> imagedata.image.shape
(1042, 1024)
>>> imagedata.data_filename
'N1454725799_1.IMG'
Thanks for getting back to me this fast. Loading the label file works. I do not get the error message anymore, but the image looks like pure noise. I will clean up my virtual environment, reinstall and try again.
That image is pretty much noise. Perhaps try this image (from the same archive directory), which is a nice view - cropped below.
https://pds-imaging.jpl.nasa.gov/data/cassini/cassini_orbiter/coiss_2001/data/1454725799_1455008789/N1455008789_1.LBL
https://pds-imaging.jpl.nasa.gov/data/cassini/cassini_orbiter/coiss_2001/data/1454725799_1455008789/N1455008789_1.IMG
I tried N1455008789_1.LBL and W1837766238_1. I got the LBL, IMG and JPEG file. The JPEG displays correctly, but the LBL has this striped structure. Something is going wrong during the binary import.
I have created a Jupyter Notebook to demonstrate:
W1837766238_1:
N1455008789_1:
Does anybody have an update on this? I have the same issue when opening images from HiRISE. Is this a problem with how I am opening the file?
@muyajil @putza Sorry, I'm going to try to figure this out this week. I think it has to do with how the data is stored in the file and the label should have some information to extract the image correctly. But this will take some time reading through documentation. Hope to have a note book viewer example by the end of the weekend
Here is some information I previously collected in response to the initial issue noted by @putza. I've been meaning to post this - I don't want @pbvarga1 to waste his time with the work I've already done. The solution to the issue lies in the documentation and highlighted sections I've gathered below, and is summarized at the end of the post. At present I don't have time to actively develop an explicit solution (MS thesis crunch time!), but this should help provide the necessary "leads" to resolve the issue. Hope this helps!
https://pds-imaging.jpl.nasa.gov/data/cassini/cassini_orbiter/coiss_2001/catalog/isswa_inst.cat
https://pdsimg.jpl.nasa.gov/data/cassini/cassini_orbiter/coiss_2103/document/edrsis.pdf (updated)
(alternatives to the previously proprietary CISSCAL IDL routine)
http://pds-rings.seti.org/cassini/iss/software.html (Cassini-specific) https://www-mipl.jpl.nasa.gov/vicar_open.html https://www-mipl.jpl.nasa.gov/external/vicar.html https://github.com/nasa/VICAR/blob/master/vos/docsource/vicar/VICAR_build_2.0.pdf
http://www.ciclops.org/sci/docs/ISS_Data_User_Guide_141215.pdf http://www.ciclops.org/sci/docs/InFlightCalibration.pdf (West et al., 2010)
http://pds-rings.seti.org/volumes/COISS_0xxx/COISS_0011/calib/lut/lut.tab & https://pds-imaging.jpl.nasa.gov/data/cassini/cassini_orbiter/coiss_0011_v2/extras/cisscal/cisscal_delut.pro
http://pds-rings.seti.org/vol/COISS_0xxx/COISS_0011/calib/
In general, issues seem to originate from Table conversion of bit depths for the imagery. 12 bit to 8 bit lossless conversion from 16 bit analog stored from sensor. Lossy or lossless compression may follow to 8 bit. Number of header lines consisting of [0,0,0,0......]'s in label defined by e.g, ("N12345678_1.IMG",4) where 4 is the line number in the data where the image object data begins. So image data starts at the fourth row down in this image. Three rows of [0,0,0,0......] preceed it.
Thank you @tjslezak. This is very helpful. My new job left me with very little time to follow up on this, but there is a long weekend coming up. I will have an update soon.
did anyone ever get to the bottom of this? seeing the same striped images as @putza with Cassini images.
I haven't kept up with this issue nor with the progress in this project but I seem to recall that we didn't initially add support for these:
OBJECT = LINE_PREFIX_TABLE
INTERCHANGE_FORMAT = BINARY
ROWS = 1024
COLUMNS = 7
ROW_BYTES = 24
ROW_SUFFIX_BYTES = 1024
^LINE_PREFIX_STRUCTURE = "PREFIX2.FMT"
END_OBJECT = LINE_PREFIX_TABLE
OBJECT = IMAGE
LINES = 1024
LINE_SAMPLES = 1024
SAMPLE_BITS = 8
SAMPLE_TYPE = SUN_INTEGER
LINE_PREFIX_BYTES = 24
END_OBJECT = IMAGE
The progressively stripey appearance in your images is what the un-interpreted line suffix/prefix look like.
perhaps this might be a good opportunity to see how planetaryimage and gdal (as optional) can be somehow used in concert. BTW, for gdal image reads, to grab the whole label for Python, we still heavily rely on the pvl library. Anyway, it seems impossible to get plaentaryimage or gdal to work an all PDS3 labels so perhaps we can use both to cover more use cases. Planetaryimage is still a good default, and if we can catch a failed read, then bounce to gdal to give it go...? gdal might also help with larger images, map projection capabilities, and other formats (there is now even some support for PDS4 labels). @putza - great notebook. I took it and tested gdal's "Open" on the labels and it somehow managed to support your examples. https://gist.github.com/thareUSGS/859b3b0d0764abdc3088b297fa039757
wow I had no ideal gdal could handle these kind of images.
by extension, that means that the excellent 'rasterio' python library by @mapbox can also read them. I've just confirmed this.
ndarray = rasterio.open("N1455008789_1.LBL").read()
Just to report, I'm getting a similar problem with DAWN VIR data cubes.
It seems that DAWN uses a different key (^QUBE rather than ^IMAGE) to point into their data cube from the .LBL file.
I think a good option would be to give users the chance to pass the Key as an argument.
I am trying to execute
imdata = PDS3Image.open('./Data/02NASA_Cassini/N1454725799_1.IMG')
in my Jupyter notebook, and I see the following error:My default Python evironemnt is
I will try some debugging over night, but would really appreciate any help.