Fail to jisgaw Io Images (Galileo/Voyage mission)

[zhouxuanxiao]

Hi Guys,

I am trying to mosaic some Io images, but it fails to jigsaw these images, here is the report:

**USER ERROR Unable to bundle adjust network [xxxxx .net] ERROR Bundle did not converge within MAXITS [50] iterations [xxxxx. net]**

when I process the Io images, I follow this: gllssi2isis, spiceinit, gllssical, noisefilte, trim, footprintinit , findimageoverlaps, autoseed, pointreg, jigsaw, cam2map and automos.

But the test 3 or 4 images do not seem to mosaic together and I find that it fails when doing jigsaw (haven't good control networks to improve camera pointing), so does anyone have some solutions?

Kind thanks.

[lwellerastro]

Please provide your command line for jigsaw (what are you solving for?). Also, what do you think about the quality of the control network you have created? It doesn't take much for jigsaw to catastrophically fail on fly-by data, particularly if there are points along or even off image limbs, and/or poorly registered points.

I have successfully bundled (via jigsaw) Galileo and Voyager data for Europa, but it was not a a simple, straightforward experience. In Astrogeology cartographers have also bundled and updated images of Io from the Galileo mission in the past (not sure about Voyager, but possible) and there are updated camera kernels available for some images.

You can see if your images pick up the updated spice by running spiceinit from=image.cub cksmithed=true

then check the on-screen results and/or the image label for InstrumentPointingQuality = Smithed in the Kernels Group. If all of your images have Smithed pointing then you shouldn't have to create a network and run jigsaw, but the images you are working with might not have updated spice.

[zhouxuanxiao]

After basic processing, I followed like this:

_footprintinit -batchlist=tr.lis from=\$1 maxemission=85 maxincidence=85 findimageoverlaps fromlist=tr.lis overlaplist=overlaps.lis errors=findimageoverlaps_error.lis detailed=true overlapstats fromlist=tr.lis overlaplist=overlaps.lis detail=full to=overlapstats.txt autoseed fromlist=tr.lis deffile=autoseed.def overlaplist=overlaps.lis onet=autoseed.net errors=autoseed.err networkid=Io_trial2isis pointid="io????" description="Io_trial2_isis" cnetbin2pvl from=autoseed.net to=autoseed_pvl.net pointreg fromlist=tr.lis cnet=autoseed.net deffile=autoRegTemplate.def onet=pointreg.net flatfile=pointreg.txt cnetedit cnet=pointreg.net onet=pointreg_new.net jigsaw fromlist=tr.lis cnet=pointreg_new.net onet=jigsaw.net update=yes errorpropagation=yes file_prefix=jig__

Anyway, kind thanks for your reply.

[lwellerastro]

Thanks for the details @zhouxuanxiao. By default you are solving camera angles and twist which is fine for framing camera images.

The most likely scenario is there are poorly registered measures in your network (very common). In order to identify these, you should try running jigsaw setting maximum iterations to something much smaller than the default 50, maybe just 2 or 3 to start. Since you said it ran to 50 iterations without convergence, you are effectively forcing it to give you some sort of output by making it stop sooner. I do not recommend setting update=yes until you have a clean network and jigsaw reports sigma0 < 1.0 during it's final iteration. Once it seems the network is clean and jigsaw is producing stable results, then you can update your images. Until then, run with update=No. You might wait to turn on errorpropagation until you have better results as well. I would also solve for radius (radius=true) to help with solution.

Since you are likely to have to run jigsaw multiple times you might explicitly name the output network and file_prefix to keep track of things like my example below.

jigsaw fromlist=tr.lis cnet=pointreg_new.net onet=jigsaw1.net maxit=3 update=no errorpropagation=no radius=yes camera=angles twist=yes file_prefix=jig1

Be sure to look at the output file jig1_residuals.csv to identify measures with poor residuals to either remove or fix manually. You could/should also look at the output network in qnet where you can sort or high residuals and visually identify problems to fix manually there.

If you have a very high sigma0 (>>1) and many measures that have very high residual (>>4-5) and with very visible mis-registrations, then you should really go back pointreg and improve the deffile settings. In fact, it looks like you just used the system default which is not likely to work on these data. See pattern matching suggestions in this document.

The process of creating a good network can be quite complicated and the default settings in the software rarely work for the outer planets. They tend to be based on high resolution mapping data that are already fairly well registered. See the Control Networks section here for additional information, though much of this is generic. There is a lot of trial and error with control networks.

[zhouxuanxiao]

Kind thanks for your careful help, I will try first to improve my pointreg and jigsaw results. Same as what you mentioned, there is a high sigma0 and I am trying to use Io global DEM as a shape model in spiceinit to improve camera pointing. Anyway, I will follow your nice advice.

Best Regards!

[zhouxuanxiao]

Hi I should be able to successfully use that DEM in spiceinit (using an Io global DEM as a shape model), but jigsaw still doesn't work. I tried following your good advices, but it didn't work either. The residuals of those control points are very high, but using qview, they are well-registered (register refers to whether the control points of the two pictures are at the same position, right?) Finally, the sigma0 of jigsaw has always been very high.

---

fxf1=iodem.cub equation=f1+1821500 to=iodem radius.cubmap2map from=iodem radius.cub map=iodem,map matchmap=true to=iodem map.cubdemprep from=jodem map.cub to=iodem demprep.cub

gllssi2isis -batchlist=root lis from=\$1.lbl to=\$1 t8.cubspiceinit -batchlist=t8.lis from=\$1.cub shape=user model=iodem demprep.cubcamstats -batchlist=t8.lis from=\$1.cub attach=truegllssical -batchlist=t8.lis from=\$1.cub to=\$1 cal.cubnoisefilter -batchlist=t8.lis from=\$1 cal.cub to=\$1_nfil.cub toldef-stddey tolmin-3tolmax=2.2 samples=5 lines=5trim -katchlist=t8.lis from=\$1 nfil.cub to=\$1 tr.cub top=2 bottom=2 left=2 right=2Is* trcub>trlis footprintinit -batchlist=trlis from=\$1 maxemission=85 maxincidence-85findfeatures fromlist=findfeatures,lis match=4152r t8 tr.cub onet=findfeatures.netalgorithm=sift/sift pointreg fromlist=trlis,cnet=findfeatures.net deffile=autoRegTemplate.def onet=pointreg.netfatfile=pointreg.txt jigsaw fromlist=trlis cnet=pointreg.net onet=jigsaw1.net update=no file prefix-jig1maxits=3 jigsaw fromlist=trlis cnet=jigsaw1 2.net onet=jigsaw2.net update=no file_prefix=jig2maxits=3 jigsaw fromlist=trlis cnet=pointreg.net onet=jigsaw3.net update=no file prefx=jig3maxits=3 outlier reiection=yes jigsaw fromlist=trlis cnet=pointreg.net onet=jigsaw4.net update=no file prefix=jig4maxits=3 sigma0=1

---

[lwellerastro]

Hi @zhouxuanxiao, after talking with a colleague yesterday we'd like to learn more about the DEM you used via spiceinit and see your bundleout results. What's the DEM source and did you verify that the radius values make sense (it's better I ask and not make assumptions).

I'm also wondering if you are removing any of the high residual measures between runs of jigsaw. If not, you are essentially bundling the same network repeatedly and not actually making progress (jigsaw will calculate the apriori lat/lon/radius for FREE points (using the average of the measures) every run and not use the adjusted values from a previous run at all). Using the onet from jigsaw as the cnet in the next run is not uncommon and I do it all of the time, but only after I have cleaned out the high residual measures either manually or via cnedit (using a deffile to identify and remove measure with residual greater than some value). Just want to check if there were undocumented steps between jigsaw runs in you method above.

Before we ask for your data (and only if it's a very small dataset), would you mind uploading the files bundleout.txt and residuals.csv so we can see some results? Since bundleout.txt can be somewhat large, please use "Attach files" instead of copying and pasting everything in a reply. If that doesn't work I will give you my email address so you can send it that way.

FYI - since you didn't specify anything for the jigsaw parameter FILE_PREFIX, the bundle out report files are being written over with every successive run of jigsaw. In the future, I recommend you use the FILE_PREFIX to uniquely name your output. For instance in your first run, setting file_prefix=jig1 would generate the files jig1_bundleout.txt, jig1_residuals.csv, jig1_bundleout_points.csv and so on.

Edit: Any chance the DEM you used was downloaded from the supporting information for this paper by White et al., 2014?

[zhouxuanxiao]

Many thanks for your kind reply and follow up.

I did use the DEM from the paper you mentioned in your edit, while the radius value was obtained from https://nssdc.gsfc.nasa.gov/planetary/factsheet/joviansatfact.html.

For the jigsaw runs, from the residuals.csv file, it seems to me that all points have a very high residual, so I am not sure what to do with it. Attached are the bundleout.txt and residuals.csv files from my first jigsaw run. By the way, actually I did specify the file prefix during my jigsaw runs, but thank you for your reminder once again. jig1__bundleout.txt jig1__residuals.csv

[lwellerastro]

Hi @zhouxuanxiao,

I processed the 3 images recorded in your bundleout.txt file (sorry I missed the fact that you did create unique output via file_prefix) in a similar manner as you did (minus using the DEM in spiceinit) and created a small network of 6 points that I manually selected and registered via qnet. (I spent a few minutes trying autoseed/pointreg and moved on because the spice is so poor between at least two of the images (offsets of hundreds of samples and lines) that it was going to take a bit more time finding the pointreg deffile that would get good registration. I knew I could pick a few points between the overlaps quicker and more accurately.)

When I ran jigsaw the same way you did I got very similar results - sigma0=1405597 in 10 iterations (maxits I used) and my maximum residual was 1894688.66438425. There are some key parameters that need to be set to get this bundle under control that I noticed when I looked at your bundleout.txt report.

This is how I recommend running jigsaw for these images (assuming the measures on the points are well registered (features match)):

jigsaw froml=clean.lis cnet=manual.net \
        onet=JigOut_manual.net \
        radius=yes update=no \
        sigma0=1.0e-10 maxits=10 \
        camsolve=angles twist=yes \
        spsolve=none \
        camera_angles_sigma=1 \
        point_radius_sigma=500 \
        file_prefix=RadAngTwist

This converged in 4 iterations ending up with a sigma0=0.333 and maximum residual of 0.47.

Note that I am solving for radius(I recommend this), camera angles and twist and placed constraints on the radius and camera angles via the parameters point_radius_sigma and camera_angles_sigma. The above sigma settings were ones I used for creating a global control network of Europa using SSI data so I thought it would work here as well.

You don't have to solve for radius, but you should expect your sigma0 and residuals to go up some. I always solve for radius in my networks because it seems to help reduce the overall error.

After looking at the bundleout.txt output for these 3 images, you could make the camera angle sigmas smaller (maybe 0.5 decimal degrees) because all of the corrections were <0.3, but 1.0 is fine and might be best if/when you work with more images. The radius corrections on my points were < 500 meters.

Give the new settings a try and let us know how it goes.

I've uploaded my bundleout.txt and residuals.csv for reference RadAngTwist_bundleout.txt RadAngTwist_residuals.csv

[zhouxuanxiao]

Thank you very much for your suggestions and time to help. I followed your procedures and jigsaw successfully ran (at least for these 3 images).