specpix count overun

[ascbot]

---

Author Name: Christopher Isbell (Christopher Isbell)

Original Assignee: Tyler Wilson

---

Hello,
FYI, looks like allocation for pixel counting is not adequate. e.g. see command and negative count values reported below.
Thanks,
Chris

astrovm3.wr.usgs.gov{cisbell}98: specpix from=tc_eve_v02_090_099.cub to=tc_eve_v02_090_099_spxls.cub hismin=-0.41 hismax=-0.39 hrsmin=-0.421 hrsmax=-0.419 lrsmin=-0.441 lrsmax=-0.439 nullmin=-0.61 nullmax=-0.459
specpix: Working
100% Processed

1. The number and type of pixels created
   Group = Results
   Null = -609021389
   Lrs = 4644
   Lis = 0
   Hrs = 41910006
   His = 49711598
   Total = -517395141
   End_Group

[ascbot]

---

Original Redmine Comment
Author Name: Tammy Becker (Tammy Becker)
Original Date: 2013-07-03T15:12:57Z

---

Reporter priority: Minimal, reporting problem only. (moved from the Impact field that is intended for developer/code impact statement).

[ascbot]

---

Original Redmine Comment
Author Name: Tammy Becker (Tammy Becker)
Original Date: 2013-07-03T16:38:16Z

---

The image results are correct, but the reporting of special pixel value count is incorrect. The count is correct with smaller images, but this count is incorrect with large images that have a large number of special pixel values, for instance, the image that revealed this problem is 36865 Samples x 737297 Lines with alot of intended NULLs.
Location of Chris' file:
/scratch/cisbell/TCO_EVE_full_res_mosaic/v02/all_mosaics/tc_eve_v02_090_099.cub

[ascbot]

---

Original Redmine Comment
Author Name: David Miller (David Miller)
Original Date: 2015-08-13T00:08:56Z

---

Verified that the source of the problem is a wrap around on the count variables. I verified this by making a cube of 1-byte pixels just large enough to overflow the max value of the counters (Specifically, 23,170 samples by 23,171 lines by 8 bands). I verified the math by hand and saw that the amount overflowed was exactly the difference of the number of bytes in the cube and the number of possible values of a 4-byte int.

[ascbot]

---

Original Redmine Comment
Author Name: David Miller (David Miller)
Original Date: 2015-08-17T21:54:30Z

---

Found that there is an existing Isis type for large ints called BigInt. Changed to make use of BigInt and reran tests. Rebuilding for prog6 so reporter may test.

[ascbot]

---

Original Redmine Comment
Author Name: Tyler Wilson (Tyler Wilson)
Original Date: 2015-09-10T21:53:53Z

---

The directory for testing this application can be found in:

/work/projects/isis/latest/m01699_1/isis/src/base/apps/specpix

[ascbot]

---

Original Redmine Comment
Author Name: John Shinaman (John Shinaman)
Original Date: 2015-10-01T01:36:25Z

---

The program has been tested successfully. The test data are located in /work/users/jshinaman/Support/RM_1699.

[ascbot]

---

Original Redmine Comment
Author Name: Christopher Isbell (Christopher Isbell)
Original Date: 2015-10-02T22:52:31Z

---

Thanks. Test data look good. And, I ran a quick test on a previous Kaguya file, and output counts look good.