Project

General

Profile

Bug #800

cubeit bug

Added by Tammy Becker about 6 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Applications
Impact:

cubeit will now work as expected on cubes with tracking bands. cubeit will also now remove all tracking information from the input cubes.

Software Version:
Test Reviewer:

Description

External Isis Support Link:
https://isis.astrogeology.usgs.gov/IsisSupport/index.php/topic,3457.0.html

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.

A possibility:
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...

Thanks,
Josh Cahill (APL - LRO/MiniRF Team Member)


Related issues

Related to ISIS - Bug #830: Applications which average or interpolate pixels should not transfer the tracking information Acknowledged

History

#1 Updated by Tammy Becker about 6 years ago

Triage Priority set to 4 due to the fact that Josh figured out a 'work around' for now.

#2 Updated by Anonymous over 4 years ago

  • Target version deleted (150)

#3 Updated by Stuart Sides almost 4 years ago

  • Target version set to 3.4.7 (2014-08-27 Aug)

#4 Updated by Kristin Berry almost 4 years ago

  • Assignee set to Kristin Berry

#5 Updated by Kristin Berry almost 4 years ago

  • Status changed from Acknowledged to In Progress

#6 Updated by Kristin Berry almost 4 years ago

  • Impact updated (diff)

#7 Updated by Kristin Berry almost 4 years ago

Could not reproduce. Instead, found a different bug #2093. Currently waiting on a reply from Josh with more details/data (see above external isis support link.)

#8 Updated by Kristin Berry almost 4 years ago

Could not reproduce general problem, without a tracking band, with Isis 3.4.0, 3.3.1, or the current beta.

#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 =
output.cub+1
output.cub+1
.
.
.
output.cub+1

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.

#10 Updated by Kristin Berry over 3 years ago

  • Impact updated (diff)

#11 Updated by Stuart Sides over 3 years ago

  • Target version changed from 3.4.7 (2014-08-27 Aug) to 3.4.8 (FY15 R1 2014-11-26 Nov)

#14 Updated by Stuart Sides over 3 years ago

  • Target version changed from 3.4.8 (FY15 R1 2014-11-26 Nov) to 3.4.9 (FY15 R2 2015-03-26 Mar)

#18 Updated by Kristin Berry over 3 years ago

To improve test coverage while I was here, I also added simple tests for the proplab=(some cube) option and to make sure the bandbin group is being constructed correctly.

#19 Updated by Kristin Berry almost 3 years ago

  • Related to Bug #830: Applications which average or interpolate pixels should not transfer the tracking information added

#20 Updated by Kristin Berry almost 3 years ago

Decided to remove all tracking information (tracking bands and associated table) from all input cubes to cubeit.

#21 Updated by Kristin Berry almost 3 years ago

  • Impact updated (diff)

#22 Updated by Kristin Berry almost 3 years ago

  • Status changed from In Progress to Resolved

cubeit now strips all tracking information from input cubes. If the only input is TRACKING bands, it throws an error.

To test, setisis /work/projects/isis/latest/m00800/isis

#23 Updated by Tammy Becker almost 3 years ago

  • Status changed from Resolved to Feedback

ran into a problem with trying to stack a cube that contained the mosaic count band.

It crashed with a filter name error.

#24 Updated by Kristin Berry almost 3 years ago

I'm having trouble reproducing the crash with a cube with a count band. Could you point me toward your test data?

#25 Updated by Tammy Becker almost 3 years ago

Test area:
/work/users/tbecker/IsisWorkshop/OSIRIS-REX_FY14/UofA-Eros/57IMG_027-4_1_14_2001_027/

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].

57mos-Controlled-dsk-AVG.cub:
Group = BandBin
FilterNumber = (3, 3_Count)
Center = (760, Null)
End_Group

#26 Updated by Kristin Berry over 2 years ago

  • Status changed from Feedback to Resolved

It turns out either the FilterName or FilterNumber keyword is used for the list of filter names in the BandBin group.

To test again: setisis /work/projects/isis/latest/m00800/isis

#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
100% Processed
cubeit: Adding band 1 of 3
100% Processed
cubeit: Adding band 2 of 3
100% Processed

...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
100% Processed
cubeit: Adding bands from Cube 1 of 2
100% Processed
cubeit: Adding bands from Cube 2 of 2
100% Processed

...since we only have access to the cube number at the point that this output is generated.

#29 Updated by Tammy Becker over 2 years ago

  • Status changed from Resolved to Closed

Tested it with the last changes made and it works well. I like the results message informing the user that an input 'track' band was not propagated.

Thank you!

#30 Updated by Kristin Berry over 2 years ago

Got testing up to 100% for new things before checking in, and looked over my previous timecards/notes for a more accurate estimate of time (this was a big ticket!)

Also available in: Atom PDF