CAM2MAP Only Map-Projects First Layer in a CUB for Some Cameras (at least MARCI)

[astrostu]

ISIS version(s) affected: 4.x.x (and later?)

Description
Running CAM2MAP on a cube file with multiple bands will output the same number of bands map-projected, but only the first will have data.

How to reproduce
Process an image, and run PHOCUBE on it. Map-project the PHOCUBE file and take a look at it, and the different bands, in QVIEW. You should be able to see what I mean.

Possible Solution
I don't know ...

Additional context
It seems like this is a bug since all of the bands or layers from the original cube are present in the output, just completely empty. If this is expected behavior, that should be documented somewhere obvious, and you should probably remove the blank layers/bands. I discovered this issue when working with MARCI data and trying to shift my order of operations, whether it's faster to do certain things before others, and while running PHOCUBE on the unprojected file and then map-projecting was much faster for larger lat/lon ranges, it isn't usable if the data aren't propagated through. For now, I'll use a work-around and split those backplanes out and do the map-projection on them. Which will still be faster than doing PHOCUBE on the map-projected version.

For the "... for some cameras (at least MARCI)" part, see the first two comments.

[lwellerastro]

@astrostu, I just tried this for a Galileo SSI image and I don't experience the same problem (we created phocube backplanes for the Europa updated products, but projected first then ran phocube, so I had data handy to compare to).

My steps: phocube from=/work/projects/EuropaBasemap/lweller/GLL_VGR_Network/Final_Updated_Lev1/s0484884313.lev1.cub to=s0484884313.lev1.pho.cub dn=false phase=true emission=true incidence=true latitude=false longitude=false pixelresolution=true

cam2map from=s0484884313.lev1.pho.cub to=s0484884313.lev2.pho.cub map=/work/projects/EuropaBasemap/lweller/Galileo/equi_clon180.map pixres=mpp resolution=214 defaultrange=minimize lonseam=continue interp=bilinear

I ran this under isis5.0.2. All four phocube bands were present in the ouput cam2map file.

Perhaps this is a MARCI problem?

[astrostu]

Hmmmmm... I tested this on MARCI again on a different computer and it failed to write out all the data again (giving no errors). The only other body's data I had readily available is Charon, so I just did a quick test on that, and it worked fine. That'd be weird that it doesn't work for one instrument but does for others. I just tried changing the warpalgorithm to see if that changed things. It didn't, so it still seems like it's an issue with MARCI (at least MARCI) and not New Horizons -LORRI nor Galileo -SSI.

I'll change the title if I can.

[lwellerastro]

I also went through the motions for a Kaguya TC image thinking maybe it was framer vs line scan issue, but Kaguya works as well. Looks like it's boiled down to Marci a bit.

[astrostu]

@lwellerastro Could you try it with THEMIS? That's also a push-frame, as is LROC-WAC. I think those two, plus MARCI, are the only three push-frame cameras in planetary science? At least that are currently flying.

[lwellerastro]

@astrostu, I was testing on datasets I am currently working with and Themis VIS was not one of them (Themis IR is line scan). However, I keep things and I had a Themis VIS test file for a different bug from long ago and re-ingested that data to run a test (under isis5.0.2).

I don't have much experience with Themis VIS so maybe that's why I encountered problems? I ran thm2isis then spiceinit on the output even.cub. Phocube ran successfully (on band 1), but when I tried to qview the output, qview seg faulted. Cam2map also seg faults. This is not a problem I'm willing to pursue right now since I am not working with this data set and simply don't have the time.

Push frames don't seem to have gotten much love in isis, but they are kind of a weird camera.

[astrostu]

@lwellerastro Okay, thanks for looking. Yes, push-broom cameras are weird. Maybe this will provide the programmers with enough info? Meanwhile, I'm using the work-around I noted: PHOCUBE, EXPLODE, CAM2MAP, rather than PHOCUBE, CAM2MAP, EXPLODE.

[Kelvinrr]

Alright, good news is I was able to replicate the error, the bad news is Marci images are too big to map project on it's own and for some reason cropping causes issues with the camera model (fails to load Spice Tables for whatever reason). @astrostu Do you have a good example of a small Marci image? I'll dig through images for now but it'll be great if there is a good small minimal example image.

[astrostu]

@Kelvinrr MARCI images are basically the same size except when spatial-summing is set to 2 or "8." So, look for any PDS image that's around 25 MB that has "MA" in the name (roughly half of the MA images are spatial-summing 1, and half are 2), or any of the MU which are ultraviolet and always are spatial-summing 8. (okay, the automatic markup on here is removing my underscores (_) in front of and behind the MA and MU)

And yes ... the cropping ALSO causes weird issues: If you crop too much, the odd framelets will not project with CAM2MAP well, but the even framelets still seem fine. That's another bug. It might have something to do with ISIS not knowing how to pick the correct patchsize in CAM2MAP, because when I try to set it manually for the odd framelets image, it looks a lot better.

Meanwhile, I was experimenting on Thursday: This issue seems like it might resolve itself if you split the PHOCUBE output (EXPLODE) but then simply re-combine it (CUBEIT). And then map-project. That might help you track down the error.

[Kelvinrr]

Alright I was able to replicate with a cropped Marci image. It seems as long as I don't have a partial framelet in the cropped image the camera model doesn't complain. Iteration is pretty quick as I try to find the issue.

[astrostu]

Ah, I hadn't noticed that it was an issue with partial framelets (I assume partial along-track? or ANY cropping across-track is the issue?).

[Kelvinrr]

@astrostu I assume along track, I haven't tried cross track.

So far it seems like the problem is that cam2map is completely skipping everything except band 1 on a marci image, when I come back to this I need to see exactly why this is.

[Kelvinrr]

So this is definitely a band dependency issue. Essentially, Marci being a band dependent camera model, some code executes when MarciCam::SetBand is called that is supposed switch to another filter on another, but there are none since the bands are now the output of phocube. Im surprised it isn't failing more catastrophically as this is causing the the camera model to read past the end of a handful of arrays.

Forcing the camera model to use the first bands filter properties for all bands in a case where there is 1 filter but n bands solved the problem and now all the bands get projected, but I am not 100% convinced the problem is just marci or if the problem is how cam2map interacts with any band dependent camera model which have had phocube run on it. I'll get a second opinion in the AM during the standup and probably have an update after then.