cubeit will now work as expected on cubes with tracking bands. cubeit will also now remove all tracking information from the input cubes.
External Isis Support Link:
I've noticed in the latest release of ISIS (Mac at this point) that cubeit is acting usual. Specifically, given an number of single band image .cubs to cube the last one is always anomalous. For instance, I have three mini-rf mosaics that I'm using cubeit to combine. The third band by its self looks fine. When combining the images with cubeit it gives anomalous values (-1.67756 e+07 values). If I add a fourth cube to the list, suddenly that fourth one is anomalous and the third one combines into the cube correctly.
I've been using the 'track' feature when mosaicing data strips in 'automos'. I do some math with different products using the first band (or the data band of these mosaics). I don't understand why this might cause a problem, but this is the only thing I'm doing differently. So, other than looking into 'cubeit' looking at using 'cubeit' on 'automos'd tracked' products may be the issue.
For the time being just adding that extra band+1 when using cubit seems to get around this problem...
Josh Cahill (APL - LRO/MiniRF Team Member)
#9 Updated by Kristin Berry almost 4 years ago
Was (finally) able to reproduce with a tracking band. (I mosaiced an lroc left and lroc right image using automos with tracking on. See: /work/users/kberry/m00800Test) If there is a single mosaiced file with 1 data band and 1 tracking band named output.cub, and we have an input list for cubeit, inputList.lis =
No matter how long the list, cubeit will put the tracking band as the last band in the output file (instead of the actual last band requested, output.cub+1.) This is because cubeit uses ProcessMosaic internally. ProcessMosaic notices that the input cube(s) has a tracking band/tracking table, and concludes that it needs to do more tracking and reserves the last band of the output file for this purpose. It then adds to the old tracking table and old tracking band, incorrectly. This results in an unusable tracking band. A similar thing happens when running automos on 2 cubes with tracking bands: the resulting tracking band doesn't work/produces garbage. The problem is in how ProcessMosaic tries to add to an existing tracking band. This problem in ProcessMosaic definitely affects cubeit and automos, and has the potential to affect handmos, mapmos, uncrop, and null, all of which use ProcessMosaic or its children. I was unable to find any problems with uncrop or null, but only tested with 1 cube.
#25 Updated by Tammy Becker almost 3 years ago
input list: stackforcubeittest_M0800.lis
349 output: stackforcubeittest_M0800-output-isis349.cub
Error: Invalid cube in the list file [stackforcubeittest_M0800.lis]. PVL keyword [FilterName] does not exist in [Group=BandBin].
Group = BandBin
FilterNumber = (3, 3_Count)
Center = (760, Null)
#27 Updated by Kristin Berry over 2 years ago
- Target version changed from 3.4.9 (FY15 R2 2015-03-26 Mar) to 3.4.11 (FY16 R1 2015-10-28 Oct)
Adding output to the Results group or print file to indicate that tracking bands were not propagated to the output cube (including which input files they were not propagated from) at Tammy's request.
#28 Updated by Kristin Berry over 2 years ago
It's ready for testing again! In addition to adding the "Tracking band removed" stuff to the Results group (so that is displayed on the screen and also in the print.prt,) I changed what it outputs as it progresses because it was wrong!
It used to output (for your example)
cubeit: Allocating cube
cubeit: Adding band 1 of 3
cubeit: Adding band 2 of 3
...because the first number is actually the cube number and the last number is the total number of bands.
Now it outputs:
cubeit: Allocating cube
cubeit: Adding bands from Cube 1 of 2
cubeit: Adding bands from Cube 2 of 2
...since we only have access to the cube number at the point that this output is generated.