Adding long/lat to Voyager2 images using phocube

[JuB104]

Hello everybody!

I’m very new to ISIS and could need some help on the phocube program.
I recently started a research project focusing on Neptun and Uranus. The first step of this project is to assign longitude and latitude to Voyager2 images of the two planets. To do so, I converted the images to .cub format using voy2isis and then added the informations from the SPICE kernels using spiceinit. All of this works so far, as does the phocube program, which I used the following way:

phocube from=testuranus.cub to=finalresult.pho.cub longitutde=true latitude=true

This indeed maps the image to lon/lat coordinates, however the resolution is very bad and overall the image seems different from the original input. Is there some parameter that can change this? There is also the notion of bands that appears quite often, and I have to admit that I do not completely understand the meaning of it. It seems that the parameter dn is also quite important, maybe someone can explain this further?

Also I have only done this so far for single images, does somebody know how I can apply this procedure to a few thousand images without having to go through every single one of them?

I am very grateful for every input.
Thank you.
All the best,
JB

[lwellerastro]

@JuB104

This indeed maps the image to lon/lat coordinates, however the resolution is very bad and overall the image seems different from the original input. Is there some parameter that can change this? There is also the notion of bands that appears quite often, and I have to admit that I do not completely understand the meaning of it. It seems that the parameter dn is also quite important, maybe someone can explain this further?

Phocube is equipped to create numerous output bands if requested. Running “phocube -h” on the command line will show you all the parameters available and their default settings (documentation found here). Using the default settings, or running in the manner you shared will create a 6-band output file containing bands for SPECIALPIXELS, PHASE, EMISSION, INCIDENCE, LATITUDE, and LONGITUDE values. Set the default TRUE parameters to FALSE in the command line if you do not want them on output. Setting DN=True will result in the original data being propagated to the output image.

See the the phocube output file’s label for description of what band contains the information you generated. The BandBin Group will contain something like this depending on what you asked for:

Group = BandBin
Name = (“Phase Angle”, “Emission Angle”, “Incidence Angle”, Latitude,
Longitude, “Right Ascension”, Declination)

Since you did not use DN=True the original image data is not in the output file. What you see in the individual band is not image data at some resolution, but rather the value of the selected parameter contained in the band. Pixels in the emission angle band will contain the emission angle value for that particular location on the target. You can view different bands using qview and the Band Selection Tool.

Try using the -batchlist parameter to run phocube multiple times. Phocube is slow and this process may take a long time on a large list of images. If you have access to a HPC that would be a better route.

By the way, you don’t need phocube to “add” lat/lon information to your images -that information is already there when you successfully run spiceinit. Phocube is providing one way to visualize and possibly use the information provided by having a camera model and spice.

[JuB104]

Great, Thanks for the tips! I will try out the -batchlist command, hopefully it will work.

Spiceinit is working for the pictures, however there seems to be a problem. As shown in the attached images, the long/lat grid is apparently shifted to the right compared to the actual planet position (Long/Lat are given at the right bottom for corresponding cursor position).

(I hope the images are visible).
I used a raw .IMQ image obtained from the PDS Imaging node, so this picture is not calibrated or processed in any way. For reference, the raw image is called C2651249.IMQ and I have applied voy2isis on it and then spiceinit. I also tried using the web=true option but it didn’t change anything. Do you know what could cause this shift?

Moreover, I would prefer to use the calibrated and geometrically corrected images provided by the OPUS website, however they are in .IMG and .LBL format and I don’t think it is possible to read them into ISIS. So I was wondering if it was somehow possible to apply phocube to the .IMQ image, and then ‘transfer’ the output bands to the correct .IMG image? I tried using the handmos application, but this didn’t allow me to combine the different bands?

Thanks again for the help!

[lwellerastro]

@JuB104

Do you know what could cause this shift?

This is a very old flyby mission and as such the SPICE acquired at the time is not very dependable. The spice applied (which is the same whether you use web=true or use kernels you have downloaded) is off the target which is what you are seeing in the images you shared. The spice says the target is one place when it is really somewhere else.

There are methods to move the spice back on to the target, but it is very tedious and manual and you will not enjoy doing it for 1000’s of images. I know this from experience as I and others did so for hundreds of Voyager images of Europa. I will share how in another reply when I get some time. Phocube is only a reflection of the current spice on the images based on the kernels used.

Keep in mind though that once the spice is co-aligned with the target, you will still see that features in one image may still not align (have the same lat/lon) with the same feature in other images. The reason is again, bad spice. To co-register/control images is also a lot of work and involves specialized processes that are unfortunately not well documented (mostly because they vary some from data set to data set and what’s out there is “canned”). Flyby data is particularly difficult.

What geometrically corrected images are you referring to? That is what you really want to work with if available. I’m just not familiar except for data we have released which is not in the pds (Europa in particular, but only a subset of the Voyager data that captured that target since Galileo SSI was better data to work with). voy2isis will only work on raw unprojected images, but you can run pds2isis on map projected images (they will have a Mapping group on output and can be viewed in qview). But if those images haven’t been controlled to the others you want to work with you will still have the problem of mis-aligned features.

[JuB104]

Hmm that is bad news, I was afraid that it would turn out to be something like this I have tried out the translate command and moving the original image by a defined number of lines and samples before using phocube, which kind of did the trick but felt more like an approximation. To do so, I used the measuring tool in qview to see how far off the picture was from the grid and then moved the picture using translate. But yeah, I don’t know if I can apply this approach due to huge number of pictures. I’m using So I’m really looking forward to your approach!

So the corrected images I’m referring to were processed using the VICAR software, in the image below is an overview of all the data that is available. The main problem I have is that the PDS label is detached in a separate .LBL file and I don’t know how to combine the .IMG and the .LBL. Applying pds2isis on the .IMG file produces an error saying that the PDS label is missing. I also tried running vicar2isis, but then I can’t apply spiceinit as there is information missing. As far as I can tell, the processed images are still misaligned compared to the spice, but applying the same translate command as for the raw images will align them. I used cubeit to add the phocube backplanes from the raw image to the corrected images, which seemed to work? Although I’m not sure about that solution, it seems a bit strange to just attach the backplanes?

Thanks for the help, I’m really appreciating it!

[lwellerastro]

Hi @JuB104, I think I’m catching up. ISIS does not support the processed file types you list above, only EDRs as per the documentation here. I searched our github issues for any past discussion on this topic and found that here.

As per the discussion in the git post, you can process the raw images such that they can be calibrated and reseau (the grid you reference?) can be identified and removed from image (and I believe but am not certain that geometric distortion is addressed as well using the reseau).

I downloaded the EDR from here (only because I couldn’t find it easily on the OPUS site you mentioned, but it seems to be the same archive) and ran the following steps:

voy2isis from=C2651249.IMQ to=C2651249.cub
spiceinit from=C2651249.cub
findrx from=C2651249.cub  (location of RX are written to the images label)
remrx from=C2651249.cub to=C2651249_remrx.cub (optional step to remove the reseaus)
voycal from=C2651249_remrx.cub to=C2651249_cal.cub

These are the steps I used when working with Voyager images of Europa. You can "more C2651249.cub after findrx and see line/sample location information of the reseau that was recorded/used during that step. As it is run here, remrx will stamp out the RX marks and fill in the void using the valid DN information around the location. Or you can select to leave the spots NULL and fill them in later using a lowpass filter. You’ll want to refer to documentation for the various parameter settings.

These steps would effectively (but not completely) produce something similar to the GEOMED data. The images would not be clean of spikes or other blemishes and may not be identical to the archive data. You could spend a lot time trying to clean these using some of the available filters in isis.

All of the other things I mentioned in a previous reply about spice being off the target in some cases and features not aligning is still valid. Whether this is an issue or not all depends on what you are doing with the data.

Attached is a view of the ingested image (left) and the calibrated image (right).

[JuB104]

Hi @Iwellerastro,

Thanks for the elaborated input! This approach does work for the .imq files I’m using, so that is great. However the coordinates grid is very important for what I’m doing, and currently I’m still trying to fix that offset. Is there any way to do this? Maybe the offset is the same for all the images and I can apply the same translate command to all of them?

[lwellerastro]

Sorry @JuB104, I’m not sure what you mean by coordinate grid. Are you talking about the reseau marks (small black marks in the left view of my figure above), or the spice being off target or something else? You can’t move the reseau at all - those are on the camera. The target being off spice requires a bit of work unique to each image that requires it and is not a simple translation that can be applied to all images. Geometrically controlling the images to each other so that lat/lon and features co-register is a bigger process which can not be summarized in this post. There are resources out there under the isis git wiki you can look into.

I said I would share some details on moving the spice onto the target, but I just haven’t had the time to resurface it. I work on a number of projects and try to help here when I can. It could be a while.

[JuB104]

Hi @Iwellerastro,
I’m sorry for the confusion, I was referring to longitude and latitude when mentioning the coordinate grid and not to the reseau marks.
Thanks for the information provided so far, they came in quite handy. I will also take a look at the isis git wiki and try out some ideas to move the spice back on target.

No worries, take all the time you need! It’s really great that you help out here in your free time, so this shouldn’t be an additional source of stress.
All the best,
JuB104

[lwellerastro]

Hi @JuB104 - I’m really sorry I haven’t been able to get back to you on this for some time. I’m attaching notes on a procedure we used here to resect (move spice onto a target) voyager images of Europa. The example is for a Europa image that you can follow along with or even download and use an example if it helps (vg_0024/europa/c2060xxx/c2060558.imq). Hmm, I’m having a problem uploading the document. If I can’t get that to work I will privately message you.

I’m not able to share a more visual presentation of the steps with you, but there is a figure in a paper for the Europa work that might help, but really, running through the process with the example image would make things the clearest. (Figure 4 in https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2021EA001935; if you can’t get access to that paper I’ll see about getting the figure/caption or I’ll do a screenshot for you).

As I said, this process is tedious and manual, but if the spice is off the target, the data are not useful from a geometric standpoint and many isis programs will produce undesirable results or just outright fail. Two of us went through the process for >200 images and it took time. You mentioned needing to do it for thousands of images, but I highly recommend you filter that list to the “best” images you have. Not all images will have spice off the target, but there’s not an easy way to determine that other than looking (from what I recall - we did this about 5 or so years ago).

Good luck!