Closed godber closed 9 years ago
Actually, if I take the resulting img.data
from the HiRISE PC_REAL
example and do img.data.newbyteorder('<')
it looks right.
Also, it would probably be more succinct if I used the <f4
or >i2
notation for creating these. I don't understand that notation yet, so I will have to look into it.
:( broken, shame felt, looks like I need to ensure sample_bytes
is an int.
I like how this has worked out.
This notebook kind of indicates the status http://nbviewer.ipython.org/urls/gist.githubusercontent.com/godber/2530f95e2986655ecaac/raw/Test_All.ipynb
Here are the data products in a json file: https://gist.githubusercontent.com/godber/34a7639cfc457150f22c/raw/4d1e3745f8e68a0d7b6106cf5cd2fba4102fb074/mission_data.json
I think I understand most of the failures here:
ESP_030168_1755_BG12_0.IMG
fails because RECORD_BYTES
isn't present. The parse_pointer
method should be called differently to support this type. #21 W1782844276_1.LBL
will be handled by #18 RA_090929123307_PIX3_LIN.LBL
no idea what this should look likeNot sure whats up with M1166071628ME.IMG
.
I have extended pixel_type to include more types and to be more explicit. The handling of floats is not yet done. It is also not yet clear to me why an assert wasn't working for me. I think the values were equivalent, just not represented the same.
This isn't ready to be merged yet, I've just pushed it for review: @wtolson
I am still trying to figure out how to express
IEEE_REAL
andPC_REAL
in numpy.refs #16