I just tried junocam2isis fullccd=yes (on a color PDS EDR file) and was surprised that the produced cubes are single band and not 3-band.
Is this the intended behavior? If not, I can open a “bug” issue on GitHub.
If this is the expected behavior, I’m curious how these “fullccd” cubes are intended to be used (map projected and mosaicked.)
I’m new to ISIS, so maybe I have some conceptual misunderstandings.
@bswift , there is a git post you might check out having a similar jigsaw error but a different data set - Jigsaw "Unable to set coefficients vector" issue with 6.0.0 · Issue #4686 · USGS-Astrogeology/ISIS3 · GitHub
Hi Brian, welcome to AstroDiscuss!
What you’re seeing sounds like the expected behavior. Rather than creating a multiband file, the “fullccd” option is meant to create a series of files where each one is a single image containing data from all of the filters on the CCD. There’s a single CCD with multiple filters bonded on different parts of the detector. The “fullccd” option allows a user to output an image as it was recorded in a single frame.
Compare the figures in Examples 1 and 2 from the junocam2isis documentation to see what this looks like.
For mapping purposes, “fullccd” should be set to “no” (which is the default). The image data be map-projected per framelet, per filter and then framelets from the same filter mosaicked into a single image. The filter mosaics could then be combined into a multiband file if desired. You can find more information about processing JunoCam images in this LPSC abstract by Milazzo et al.
Thanks for the response. I’m familiar with the JunoCam instrument, and have map-projected and mosaicked one-filter-per-cube images. However, the issue with this approach is that **jigsaw** is then free to produce non-realistic spacecraft parameters where position and orientation will have different values across the three filters from a frame/observation.
I tried setting **OBSERVATIONS=YES** for **jigsaw** (to allow the three subframes to be treated as a single observation) but that triggered this abort:
jigsaw fromlist=cnc_bs7_cubes.lis cnet=cnm_cne_ccp_bs_PJ34-2021-12-13T22:54:00.net onet=js_cnm_cne_ccp_bs_PJ34-2021-12-13T22:54:00.net update=yes spsolve=positions spacecraft_position_sigma=60000 camera_angles_sigma=1.0 file_prefix=jsbs9 residuals_csv=no OBSERVATIONS=YES
Validating network...
Validation complete!...
starting iteration 1
aborting...**USER ERROR** Unable to bundle adjust network [cnm_cne_ccp_bs_PJ34-2021-12-13T22:54:00.net].
**ERROR** Could not solve bundle adjust.
**ERROR** Unable to apply parameter corrections to IsisBundleObservation.
**PROGRAMMER ERROR** Unable to set coefficients vector. The size of the given vector [1] does not match number of coefficients in the basis equation [3].
Without the **OBSERVATIONS=YES**, the above **jigsaw** runs fine.
So, my motivation for trying to process cubes produced with FULLCCD=YES was as a workaround for the above jigsaw issue.
As a workaround for **junocam2isis FULLCCD=YES** not having an option to produce a 3-band cube, I’ve developed a script to convert a greyscale FULLCCD cube to 3-band using a combination of **trim** and **cubeit**.
The answer to this hinges upon what the fullccd option is intended to do. As originally created, it was meant to re-create what CCD actually read out before it was sliced up by filter, at least what we can re-create. I’m not sure how users want to actually use it though. The bundle adjustment process you described seems reasonable and will work both ways, one band and multi-band, but you do need to re-slice out the filters after adjustment.
This sounds like a reasonable enhancement request if you want to submit over on github: