ISIS2 user documentation not available

Is it on purpose that the ISIS2 documentation is not available (see image)?. No matter which link I click on on USGS Isis: ISIS 2 User Documentation I get the screenshot below. Specifically I would like to see the ‘Appendix A - Example Cube Label’ as I am trying to create a label.

It appears all links under that particular page are broken. Our IT alerted local users to problems with some of our public web sites being down and that may be what is causing this problem, but I don’t know that for sure.

Question -Is there something you are doing that requires an ISIS2 file? I might have an ISIS2 file sitting around somewhere that I can share the label for, but that version of isis has not been a supported version for some time now.

I’m not sure why the links to the ISIS2 docs are broken, but The Wayback Machine has a snapshot of Appendix A: ISIS Appendix A -Example Cub Label

Just to tag off of what @lwellerastro said: if you don’t specifically need to build a label for an ISIS2 cube, the ISIS3 label dictionary is available here:

1 Like

ok thank you :slight_smile: the links have been down for at least a month if not close to two (I have tried to access them before and then got distracted with some other work). I am just trying to learn more, but I am actually working with ISIS3 - I am looking for a minimum working label template. So a label that contains the minimal required information and I can’t find one.

We have .DAT files with various information and he wants to write a script to transform them to .FITS (and then from .FITS to .cub later) and for that we needed to know the information it needed to contain. Thanks again!

The “ISIS Cube Object” section at the top of the Label Dictionary I linked to describes the minimum required elements of the label: The Core object is required and must contain the Dimensions and Pixels groups.

It’s possible to convert ISIS3 cubes into FITS (and many other formats!) using gdal_translate. I know FITS is a very flexible format, so GDAL’s FITS driver may not do 100% of what you need for your particular application, but it should get it close.

Thank you :slight_smile: Yes but we want to go the other way - ie. we need to generate a .IMG from a .DAT (or a .FITS and a .LBL) and when that is passed to dawnfc2isis it should make a cube that spiceinit and asp understands. So perhaps the question is more what is required in the image label in order for the cube to work with the tools. I will look at GDAL thank you :slight_smile:

Okay, so what you really want to do is go from a FITS image to a PDS3-formatted imaged that mimics a Dawn FC image in order to pass the PDS-formatted image as input to dawnfc2isis? In that case you don’t need to know anything special about the ISIS3 label format. What you actually need is an example PDS3 label from a real Dawn FC image.

dawnfc2isis expects certain instrument-specific information to be present in the PDS label of the file it ingests.

You could still use GDAL to perform an initial format conversion from FITS to PDS3 and then write custom code to update the label on the PDS3 file to make it compatible with dawnfc2isis.

Yes exactly.
I have a .FITS file with the header:

SIMPLE  =                    T / conforms to FITS standard                      
BITPIX  =                  -64 / array data type                                
NAXIS   =                    2 / number of array dimensions                     
NAXIS1  =                 1024                                                  
NAXIS2  =                 1024                                                  
EXTEND  =                    T                                                 
INSTRUME= 'C2'                                                            
OBJECT  = 'VESTA'                                                            
OBSERVER= 'DAWN'                                                           
EXPTIME =                0.014                                                  
DATE-OBS= '2011-08-15T22:32:28.107000'                                          
TIME_END= '2011-08-15T22:32:28.121000'                                          

I can run this through the fits2isis tool and get a .cub but it is as you say missing the instrument specific information that I need to do any further work with it. Is the way to do it to use an example PDS3 label from a real Dawn FC image and kinda copy-paste the changes into that? That seems like a hack? Is there any way to find out what the minimum requirements are for the .FITS header?

Using the fits2isis seems to just echo the label and not really grab the time. How can I get FITS keyword timing into the .cub?

Just to pile on a little bit…I think all we really want to do is convert a FITS file into a CUB. I think we can ignore that it was ever real Dawn data…we’ve massaged it a bit, and now would like to turn our image data and header into something that ISIS can read.

As you say, FITS is a very flexible format, and it feels like a good pathway to bundle up both the image and the header data. I am using astropy and I can put the image array into the file and whatever header keywords are required…we just can’t figure out what fits2isis requires such that the .cub is complete at the end.

In particular, I’m worried about the time. We can convert a test FITS file and then dump the CUB, and see that it put our DATE-OBS into StartTime…but I can’t see how to give it the exposure duration or end time such that future tools can know the mid-time of the observation (for sampling trajectory, etc).

Okay, that sounds a little bit different to me than the earlier messages. If you don’t care about the cube being formatted such that it looks like it belongs to an ISIS-supoprted camera, it won’t matter whether you try and define custom keywords in the FITS label before running fits2isis or add custom keywords to the cube’s label after the fact. Further up the thread I linked to the ISIS3 label dictionary, which defines the minimum metadata required to create an ISIS3 cube label.

However, if you intend to run spiceinit on the resulting cube, the cube label will have to be formatted such that ISIS recognizes it as coming from a supported camera.

Trying to turn images of a synthetic surface collected by a synthetic camera into files that appear to have been taken by a real camera is already a hack! :slight_smile:

In theory, whether you choose to go from FITS–>PDS3–>ISIS3 or FITS–>ISIS3 doesn’t really matter. However fits2isis may not necessarily convert custom keywords in a way that will help spiceinit understand the result as a Dawn FC image. fits2isis is rather generic, just like pds2isis. On the other hand, dawnfc2isis will translate a properly-formatted Dawn FC PDS3 product into a canonical Dawn FC ISIS3 cube.

Thus, it may be possible to format a FITS header such that running fits2isis on it will result in a cube that will appear to be a Dawn FC image, which can then be passed to spiceinit directly, but I think the most reliable way to find out what metadata is required in that cube would be to pass a real Dawn FC PDS3 product through dawnfc2isis and inspect the resulting ISIS label to see how the keywords are translated.

If you’re already working in Python, you can use the pvl library to read/modify both PDS3 and ISIS3 labels programmatically.

I’d be interested to hear from someone who is more familiar with FITS and fits2isis, but ultimately, I think the FITS–>PDS3–>ISIS3 workflow is more reliable than trying to translate FITS labels directly into ISIS3 labels.

Ok thank you so much once again!
haha yes I guess I am already far down the ‘hack’-path anyways :slight_smile: