Adding jigsaw examples #4734
Adding jigsaw examples #4734
Conversation
| <p> | ||
| A relative network is a network that has no points connected to a ground source, but connects overlapping images together. Since there is no connection to | ||
| ground in the network, only camera specific parameters can be solved in the bundle. The required information to turn on spacecraft, radius, or other such | ||
| bundle solve parameters is not recommended. |
There was a problem hiding this comment.
I'm not sure if this paragraph is entirely correct. You can certainly still solve for all of these things, as long as you have enough observations for the number of unknowns, but they will all be determined relative to the spacecraft. So, the ground solution relative to the spacecraft will be correct, but the correctness of the ground solution relative to the rest of the body is unknown. You can come back and use tools like PC align to correct for this type of error.
There is likely a more technical set of terms for this, I'll reach out to Brent.
There was a problem hiding this comment.
I guess I am under the impression that within ISIS, if you do not have ground in a network then solving for spacecraft position is not really worth the effort. But I would really appreciate more certain terminology, let me know if you hear from Brent
| </p> | ||
| <p> | ||
| This relative bundle turns on and parameterizes the camera twist and camera acceleration solve parameters. Turning on camera twist allows for the bundle to solve | ||
| for the cameras rotation around the bore sight axis and does not require parameterization. Setting the camera solve parameter to acceleration is useful for |
There was a problem hiding this comment.
and does not require parameterization what does this mean? Is this saying that solving for twist is optional?
There was a problem hiding this comment.
I mean twist is a flag and does not have a corresponding uncertainty estimation requirement. I will update to be more clear.
| This relative bundle turns on and parameterizes the camera twist and camera acceleration solve parameters. Turning on camera twist allows for the bundle to solve | ||
| for the cameras rotation around the bore sight axis and does not require parameterization. Setting the camera solve parameter to acceleration is useful for | ||
| line scan imagers and requires uncertainties to be set for the angles (deg), angular velocity (deg/s), and angular accelerations (deg/s**2). These values were | ||
| set with increasing constraint because of the increasing affect alterations of higher derivative parameters have on the bundle solution. |
There was a problem hiding this comment.
Change higher derivative parameters to higher order parameters. We're still just computing first partials with respect to all of these parameters, the acceleration is a higher order term in the pointing polynomials.
| <p> | ||
| The ‘overexisting’ flag allows the bundle solution to approximate the camera solution with a polynomial function as opposed to storing every individual measurement. | ||
| This saves time and memory required for the bundle solution at the expense of accuracy. If one required the accuracy, overexisting could be used until the bundle | ||
| is converging in a satisfactory way and then turned off for the final solution. |
There was a problem hiding this comment.
This paragraph is incorrect. The bundle solves for a polynomial regardless of overexisting or not. When you do not have overexisting on, the bundle starts by fitting a polynomial to the a-priori ephemerides and then just uses that polynomial to compute all ephemerides. If you enable overexisting, it instead saves the a-priori ephemerides and begins with a zero polynomial. The a-priori ephemerides are then added to ephemerides computed from the polynomial that the bundle solves for. Here's a simple example:
overexisting off
Initial data : {(1,1), (2, 4), (3, 9), (4, 16)}
fitting a linear polynomial we get f(x) = 5x - 5
then, we throw the initial data away and we now compute all ephemerides using our function, f. So, {(1, f(1)), (2, f(2), ...}
The bundle will compute corrections to the coefficient of f.
overexisting on
Initial data : {(1,1), (2, 4), (3, 9), (4, 16)}
We start with a zero polynomial, f(x) = 0x + 0
Now, we keep the original data and add the result of f to it. So, {(1, 1+f(1)), (2, 4+f(2)), (3, 9+f(3)), ...}.
The bundle still computes corrections to our function f and because the initial data is just a constant offset, it doesn't impact our partial computations in the bundle.
| </description> | ||
| <terminalInterface> | ||
| <commandLine> | ||
| jigsaw fromlist=cubes.lis cnet=relative_reg_jig4_edit.net onet=relative_reg_jig5.net update=no file_prefix=jig5 sigma0=1.0e-10 maxits=10 \ |
There was a problem hiding this comment.
Add a not above that you have update=no because you are still evaluating the solution and do not want to apply it to your images just yet.
| Applying the point radius solve parameter requires the point_radius_sigma to be set. This value is a representation the uncertainty (in meters) of the | ||
| cameras pointing corresponding to the correct elevation on the shape model. Often this value can be set, and the appropriateness of the set value can be | ||
| checked using the 'POINTS DETAIL' section of the bundleout.txt file output by jigsaw. If the radius total correction of points exceeds the provided sigma, | ||
| the uncertainty may need to be increased. |
There was a problem hiding this comment.
Be careful correlating these too closely. We've had users confused about the sigmas not being hard constraints. They are a-priori uncertainties, or standard deviations, not hard constraints. So, it's expected that some amount of points have corrections higher than their sigmas, in fact in a perfect world, we'd expect about a third of the points to have corrections higher than 1 sigmas.
| Applying the space craft position solve parameter requires an uncertainty estimation through spacecraft_position_sigma, while [file_prefix]_bundleout_images.csv | ||
| holds the resulting image adjustments in the X Correction, Y Correction, and Z Correction columns. The overhermite flag allows a polynomial to estimate the | ||
| spacecraft position, like the overexisting flag estimates the camera pointing with a polynomial. As such, this option saves memory and time at the expense of | ||
| some loss in accuracy and this loss can be mitigated by switching it off for the final run. |
There was a problem hiding this comment.
See my comments in the previous example. using overexisting or overhermite actually takes more memory than just solving for a polynomial as we have to store the a-priori ephemerides and the polynomial.
| your update cubes camera pointing (or any kernels resulting from these updated camera pointings). | ||
| </p> | ||
| <p> | ||
| If you want to double check the update was completed, see cathist or catlab (search for ‘Jigged’). |
There was a problem hiding this comment.
It would be great to provide an example of a table that has been updated and one that hasn't. Like a before and after.
| This last example is of a final jigsaw run of a grounded network. In this example all network adjustments are done, the bundle is converging, the resulting | ||
| residuals are acceptable, and therefore we are ready to update the camera pointing on the cubes. In the final run you can turn off overexisting and overhermite, | ||
| if you want to regain the accuracy, but note that the bundle solution will differ from your previous run. Therefore, it is advisable to conduct one intermediate | ||
| run to check the bundle is acceptable without these flags before updating the cubes. Finally, during the final run we turn on the error propagation flag. This |
There was a problem hiding this comment.
I would recommend not changing any parameters besides update in the final solution. You should check that you like the whole solution before you save it. It's kind of a hassle, but there's an issue open already to allow us to apply a previous solution independently. #4474
|
Currently I have addressed all the comments I 👍 'd (or attempted to address them). I would still like to add
|
Adding examples to the jigsaw documentation.
Description
I am adding three examples; one bundle for a relative network, one for a grounded network (or ready for cube update), and a grounded network (ready for updating cubes).
Related Issue
Issue #4718
Motivation and Context
Previously there was a single jigsaw example, which ran mostly defaults. These examples, alter the default parameters while explaining the reason for the alterations.
How Has This Been Tested?
The docs were built locally and previewed before this PR was opened.
Screenshots (if appropriate):
Types of changes
Checklist:
Licensing
This project is mostly composed of free and unencumbered software released into the public domain, and we are unlikely to accept contributions that are not also released into the public domain. Somewhere near the top of each file should have these words: