<div dir="ltr"><div><div><div>Hi Trent,<br><br></div>Just wondering, as even ISIS does not import it, do you know any guys actually reading the rings images? What software do they use?<br></div>It might be worth just clarifying how they actually read them, even just for the sake of pds2isis and sanitizing the gdal driver ...<br><br></div>Cheers,<br>Yann<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 December 2014 at 10:10, Hare, Trent <span dir="ltr"><<a href="mailto:thare@usgs.gov" target="_blank">thare@usgs.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Michael,<div> This is an odd hybrid PDS/ISIS2 label. Before seeing this label I have only ever seen the "QUBE" label object within an ISIS2 file. This was <b>not</b> one of the PDS label options -- at least when the gdal reader was written. For rasters files within PDS (v3), as far as I understood, only the "^IMAGE" or "^SPECTRAL_QUBE" were allowed. I don't know the heritage of this label or when it was implemented but it is a strange beast. This is one reason, among many others, that I have always placed a caveat on the GDAL PDS readers that it probably supports about 70% of PDS images. It obviously doesn't support this type or if the image section is compressed (e.g. MOC edrs), and it will always prefer if the image is map projected and the target is a planetary surface. This PDS label is not only an odd PDS/ISIS2 hybrid label it is an image of planetary rings(!) -- I think.</div><div><br></div><div>As a check, the PDS importer in ISIS3 also fails.</div><div><div>mag{8}> pds2isis from=FUV2004_183_03_24.LBL to=test.cub</div><span class=""><div>**PROGRAMMER ERROR** Unsupported axis order [AXIS_NAME = (BAND, LINE, SAMPLE)].</div></span></div><div><br></div><div>Anyway, to possibly read the image you might be able to hack the label but this seems dangerous and would be probably still be missing something needed from the label (even though it kind-of works).</div><div><br></div><div>change</div><div>1.) ^QUBE to ^IMAGE</div><div>2.) OBJECT = QUBE to OBJECT = IMAGE</div><div>3.) END_OBJECT = QUBE to END_OBJECT = IMAGE</div><div><br></div><div>after </div><div>1.) CORE_ITEM_BYTES = 2</div><div>SAMPLE_BITS = 16</div><div><br></div><div>Again, gdalinfo will not fail but I have no idea if the data is being read correctly.</div><div><br></div><div>For this hybrid label and the fact I think the target is planetary rings I'm not sure it would be worth trying to patch GDAL to support it...? Sorry - I haven't been much help.</div><div><br></div><div>good luck!</div><span class="HOEnZb"><font color="#888888"><div>Trent</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></font></span><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Dec 8, 2014 at 6:39 PM, K.-Michael Aye <span dir="ltr"><<a href="mailto:kmichael.aye@gmail.com" target="_blank">kmichael.aye@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><u></u>
<div>
<div>
<div>An old bug (or lack of implementation) that supposedly was fixed in GDAL 1.9.0 as mentioned in this message:</div>
<div>
<a href="http://lists.osgeo.org/pipermail/gdal-dev/2014-July/039508.html" style="color:rgb(0,128,255)" target="_blank">http://lists.osgeo.org/pipermail/gdal-dev/2014-July/039508.html</a><br>
</div>
<div><br></div>
<div>might have crept up again. Or, possibly, it is just another version of the endless parameter space of the format of PDS3 binary files that the PDS reader understandably could not yet account for until somebody tried it on this older data.</div>
<div><br></div>
<div>I am trying to read the Cassini UVIS data file in this linked zip:</div>
<div>
<a href="https://dl.dropboxusercontent.com/u/139035/PDSdata-2014-12-08T17-04-46-08-00.zip" style="color:rgb(0,128,255)" target="_blank">https://dl.dropboxusercontent.com/u/139035/PDSdata-2014-12-08T17-04-46-08-00.zip</a><br>
</div>
<div><br></div>
<div>and am getting the same errors as mentioned in above forum post:</div>
<div>
<div><br></div>
<div>In [8]: gdal.Open('./FUV2004_183_03_24.LBL')</div>
<div>ERROR 1: Sample_bits of 0 is not supported in this gdal PDS reader.</div>
<div><br></div>
<div>In [9]: gdal.Open('./FUV2004_183_03_24.DAT')</div>
<div>ERROR 4: `./FUV2004_183_03_24.DAT' not recognised as a supported file format.</div>
<div><br></div>
<div><br></div>
<div>In [10]: gdal.VersionInfo()</div>
<div>Out[10]: '1110100'</div>
</div>
<div><br></div>
<div><br></div>
<div>Regards,</div>
<div>Michael</div>
</div>
<div><br></div>
<div>
— <div>Michael Aye</div>
<div>Cassini UVIS and MAVEN IUVS team</div>
<div>LASP, Boulder CO</div>
</div>
</div>
<br></div></div><span class="">_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br></span></blockquote></div><br></div></div>
<br>_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">----</div>
</div>