Do we have anything similar to ISIS 2 cpylab?
I could really use some help....I need to copy the level 1 label information (Instrument and Kernels group mostly along with the Tables that the kernels point to on the label) to a variation of the same image, but am having quite the time doing it with editlab because there are sooooooo many groups, keywords and values to get. I'm wasting a lot of time and getting no where for it doing it this way. Everytime I think I have what I need, a program I am trying to run (photomet) lets me know yet something else is missing. The images are not the same size so I can't work around this by other means.
It would help the most if we had an ISIS 3 version of cpylab or even lev1prop. I've added this request to this post
https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,2700.0.html, but in the meantime I thought I'd see if anyone had a personal script or program they wouldn't mind sharing with me. I really need this information so that I can run photomet against this second image....I can't move forward otherwise.
Currently I do not know of any way in Isis3 to copy labels between cubes.
As a workaround for this shortcoming, what I would do is a process of detaching and reattaching the labels. Now, this is dependent on the cubes being identical to the extent that they are the same sample, line, and band size, and that they are the same bit type. I believe it would be possible to do it with more differing cubes, but would require more checks and changes.
So, the steps are:
Cube a - labels wanted
Cube b - image data wanted
1. Detach labels from the cube you want the labels from, and from the cube you want the image data from. Do this using cubeatt: cubeatt from=a.cub to=...+detached and cubeatt from=b.cub to=...+detached
After this step, what you need to do is swap in the .cub file you want. So, we want to do is move a.cub to some other name, or delete it, and move b.cub to be named a.cub and in the same directory. Before we do this however, we need to verify the size of the binary data. Do ls -l and verify that the size of the two binary .cub files is the same. If they aren't, this won't work.
With the .cub file and the labels that you want together all having the same name, do a final cubeatt from=a.cub to=... which will reattach the labels and binary data back into one file.
As I said, this is a workaround. Let me know if it doesn't work. Also, you can edit the labels all you want by hand while they're detached if you need to do so.
My images, unfortunately, are not the same size. I left out the details because I was hoping someone would have a script or something I could use. I have an orthoimage from SOCET that has a mapping group on the labels, but nothing more. I need to run photomet on this image which requires level 1 camera information be on the image. I have the level 1 file that was used to build the ortho image, so I just needed to transfer the proper label information. Kinda of a bummer to run editlab so many times. I will likely have to write my own script to get around this as I will have to do this repeatedly this year with other images.
I have added the need to convert the ISIS 2 program to and ISIS 3 version under another thread.
Thanks for taking a look at my problem. I will consider how I might use your suggestion to make avoid writing a script.
Have you looked at the "tempfile" (should probably be "template") option in "editlab". If it doesn't do all you need it to, it seems reasonable to modify it to do so. I know it will not copy the content of the tables, but it would not be difficult to add that capability.
Also, since we regularly import SOCET images, should we be looking into writing an import program for it?
Thanks for pointing out the tempfile - I'll see if that helps.
As far as a socet2isis program, I don't think anyone would object. Currently, Annie has steps layed out (possibly scripts) that help get socet dem's and orthoimage's into ISIS 2 and ISIS 3. I'm pretty sure the only group she creates (via maplab) is the mapping group because most uses in ISIS are in level 2 space. In my case (for photoclinometry), I needed the level 1 information so that I could use the image in photomet to shade a dem. This is precisely why we had lev1prop under ISIS 2. And I still there is a need for cpylab in ISIS 3 - another extremely useful program under ISIS 2.
In the meantime I will see how tempfile can help. If I understand correctly, it only loads groups and keywords, right? I'd still need to run editlab a bunch of times to populate the keywords with values. Yes?
First the "tempfile" abilities of "editlab" are pretty limited, and they need more documentation. Such as, there are no modify capabilities, and objects in the "tempfile" are ignored.
That being said, all groups and the keywords within them including the comments will be added to your cube labels.
Mackenzie and I will be coming by to make sure you get what you need.
Ok, I see how to use the tempfile now.
What I did was run catlab on my level 1 image, then edited the output to retain only the Groups I wanted to propagate to the level 2 file (Instrument and Kernels). I made sure there were no Objects or Tables included. Then I ran editlab with the addtemp option. Since all the groups and keywords new and being added, this worked fine. It would be useful if this process could be used to modify.
However, this is not enough. I do need tables to be propagated. I just attempted to run photomet using my level 2 image as input with the propagated level 1 labels and it returned this error:
CAMERA ERROR Unable to initialize camera model from group [Instrument] I/O Error Unable to open Table [SunPosition]....
Not sure why the camera model is a problem, but it's obvious what the I/O error is about.
I'm not sure what all photomet needs, but in ISIS 2 I routinely would run lev1prop on a level 2 image, then go into photomet with this file and shade a DEM using the level 1 illumination information. We need a way to duplicate this. Maybe we need to talk to Janet to understand what photomet needs to run. Maybe I'm not getting all of the level 1 groups propagated that it needs (in addition to the tables).
I need to come talk to you in person. In ISIS2 we had the capability in the mosaic program to propagate level 1 labels so that we
could still run programs like photomet on a mosaic file. There is still a lev1prop program in ISIS2 that will propagate level 1 labels
to another file. The groups that are propagated included ISIS_INSTRUMENT, ISIS_GEOMETRY, and ISIS_TARGET. I need to get some
information from you to track down the problem and fix it if this capability does not already exist in ISIS3.
I am sorry to say that I will not be allowed to add this capability to the ISIS3 system for you. Apparently, adding
ISIS2 functionality to ISIS3 clutters it up and makes it hard to maintain.
#2 Updated by Lynn Weller over 6 years ago
This application is not resolved. I just tested it on some files but the program fails because the files are not of the same size. As I explained countless times in posts and via email, I need to propogate the level labels (instrument, kernels, all the blobs) to a level 2 version of the image (ortho image exported from SOCKET, so it only has appropriate Mapping Group info) so these images will never match in size. According to the documentation, if a pvl or lbl is entered as the "source" file, then "No safety checks can be done in this case". I thought this meant no checks would be done, but that is apparently not going on since I get the following error:
"Cannot copy Instruments group when the sample scaling factor
and line scaling factor do not match"
So it's clearly checking something.
I will see if I can edit this post and point to data and include a command line.
#9 Updated by Lynn Weller over 4 years ago
- Tracker changed from Feature to Bug
- Start date set to 2014-07-02
In the minds of more than a few people, not being able to propogate level 1 label/blob information to a level 2 file is still a problem, and not a feature request.
Current photoclinometry work requires this program do more, hence why I am resurfacing this post.