Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening QUB image gives pvl.decoder.ParseError #71

Closed
pedrohasselmann opened this issue Oct 7, 2020 · 5 comments
Closed

Opening QUB image gives pvl.decoder.ParseError #71

pedrohasselmann opened this issue Oct 7, 2020 · 5 comments

Comments

@pedrohasselmann
Copy link

pedrohasselmann commented Oct 7, 2020

Hi

I'm running on the following error when I try to open a QUB image cube issued from NASA/DAWN mission:

pvl.decoder.ParseError: Unexpected token b'>' (expected b'='): line 1 column 2 (char 1)

I'm passing the following commands using Python 3.8.5:

    import planetaryimage as plimg

    cube = plimg.CubeFile.open('VIR_VIS_1B_1_365887222_3.QUB'')
    print(cube.data.shape)
    print(cube.shape)
    return cube

The installation seems ok, running "import planetaryimage" or "import pvl" does not return any error.

@rbeyer
Copy link
Member

rbeyer commented Oct 7, 2020

@pedrohasselmann, so it looks like the Dawn data have detached headers, such that for each .QUB file, there is a separate .LBL file right next to it in the PDS volume.

I downloaded both, and ran:

> pvl_validate VIR_VIS_1B_1_365887222_3.LBL
PDS3 |     Loads     | does NOT encode
ODL  |     Loads     | does NOT encode
PVL  |     Loads     |     Encodes
ISIS |     Loads     |     Encodes
Omni |     Loads     |     Encodes

This tells me that the PDS label gets parsed just fine by the Python pvl library (everything "Loads"). If I do this with just the binary QUB file, I think I see your error:

> pvl_validate -v VIR_VIS_1B_1_365887222_3.QUB
ERROR: PDS3 load error VIR_VIS_1B_1_365887222_3.QUB (LexerError(...), 'Expecting an Aggregation Block, an Assignment Statement, or an End Statement, but found ">" : line 1 column 1 (char 0) near ""')
ERROR: ODL load error VIR_VIS_1B_1_365887222_3.QUB (LexerError(...), 'Expecting an Aggregation Block, an Assignment Statement, or an End Statement, but found ">" : line 1 column 1 (char 0) near ""')
ERROR: PVL load error VIR_VIS_1B_1_365887222_3.QUB (LexerError(...), 'Expecting an Aggregation Block, an Assignment Statement, or an End Statement, but found ">" : line 1 column 1 (char 0) near ""')
ERROR: ISIS load error VIR_VIS_1B_1_365887222_3.QUB (LexerError(...), 'Expecting an Aggregation Block, an Assignment Statement, or an End Statement, but found ">" : line 1 column 1 (char 0) near ""')
ERROR: Omni load error VIR_VIS_1B_1_365887222_3.QUB (LexerError(...), 'Expecting an Aggregation Block, an Assignment Statement, or an End Statement, but found ">" : line 1 column 1 (char 0) near ""')
pvl library version: 1.0.1
PDS3 | does NOT load |
ODL  | does NOT load |
PVL  | does NOT load |
ISIS | does NOT load |
Omni | does NOT load |

Of course, there's no surprise that the library can't attempt to parse PVL text from binary image data, when you know what's happening. It seems that you're maybe using the 0.3 version of pvl, instead of the latest, but that's not the issue (I get a slightly different error message, and pvl 0.3 doesn't have the pvl_validate utility).

Typically, these PDS images with detatched headers have a certain kind of PVL record in them that acts as a pointer into the data, and you usually do things with the .LBL file, and anything that knows how to read PDS data that needs the image data, will follow that PVL record that points to the image file that should be in the same directory. However, I'm not seeing that kind of record in this PDS label, but maybe planetaryimage can deal with it anyway, so you could just try giving the .LBL file instead of the .QUB file.

However, it is important to note that this is not an ISIS Cube file, and so using the planetaryimage.CubeFile object isn't appropriate. You need to use the planetaryimage.PDS3Image object.

Good luck!

@pedrohasselmann
Copy link
Author

pedrohasselmann commented Oct 9, 2020

Thanks @rbeyer ,

Actually, I have installed pvl 1.0.1.

Indeed, by passing the .LBL file rather than .QUB I get a different error message from pvl:

KeyError: '^IMAGE'

I think that means that he can't find the associated .QUB data.
Actually, in the .LBL file the keyword is ^QUBE...

I ask myself, is there a way to pass both .LBL and .QUB files through the PDS3Image argument? I can't find that option on the readthedocs.

@rbeyer
Copy link
Member

rbeyer commented Oct 9, 2020

Are you getting that error from pvl or planetaryimage?

I suspect it is coming from planetaryimage because it is attempting to do the "right" thing. It is given a file, it recognizes that the file itself doesn't have image data, but does have PVL text. In this case, planetaryimage looks for the ^IMAGE key in the PVL text that would tell it what the name of the file is that contains the image data. Unfortunately, the PDS3 standard used several different names for pointer objects, and this label uses ^QUBE instead of ^IMAGE, but apparently planetaryimage doesn't know to look for that key.

So that's an issue with the planetaryimage library, and unfortunately, it doesn't seem to have seen any development in a while, but you could try posting an Issue there.

Since the label is just a text file, you could go and try changing ^QUBE to ^IMAGE but that might screw up other things, I'm not sure.

I'm not sure what your overall goal is, but there might be better avenues to accomplish it than the planetaryimage library, I don't know. If you might find better advice on how to tackle that problem in the OpenPlanetary python Slack channel. You can just post a link to this Issue to bring everyone up to speed there, and then ask your question.

@pedrohasselmann
Copy link
Author

I'm using planetaryimage. That's what I actually thought so. I will try to open an issue there and propose to add a new input to their PlanetaryImage class where users can pass the proper key that actually matches their data label.

Thanks @rbeyer!

@rbeyer
Copy link
Member

rbeyer commented Oct 12, 2020

Good luck!

@rbeyer rbeyer closed this as completed Oct 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants