Project

General

Profile

Bug #1699

specpix count overun

Added by Christopher Isbell over 4 years ago. Updated over 2 years ago.

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

No negative impact is expected as a result of this solution.

Software Version:
Test Reviewer:

Description

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

The number and type of pixels created

Group = Results
Null = -609021389
Lrs = 4644
Lis = 0
Hrs = 41910006
His = 49711598
Total = -517395141
End_Group

History

#1 Updated by Tammy Becker over 4 years ago

  • Status changed from New to Acknowledged
  • Impact updated (diff)

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

#2 Updated by Tammy Becker over 4 years ago

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

#3 Updated by Stuart Sides over 2 years ago

  • Assignee deleted (Christopher Isbell)

#4 Updated by Stuart Sides over 2 years ago

  • Status changed from Acknowledged to Assigned
  • Assignee set to David Miller
  • Target version set to 3.4.11 (FY16 R1 2015-10-28 Oct)

#5 Updated by David Miller over 2 years ago

  • Status changed from Assigned to In Progress
  • % Done changed from 0 to 20

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.

#7 Updated by David Miller over 2 years ago

  • Status changed from In Progress to Resolved
  • Impact updated (diff)

#8 Updated by David Miller over 2 years ago

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.

#9 Updated by Kristin Berry over 2 years ago

  • Assignee changed from David Miller to Stuart Sides

#10 Updated by Stuart Sides over 2 years ago

  • Assignee changed from Stuart Sides to Tyler Wilson

#11 Updated by Tyler Wilson over 2 years ago

  • Status changed from Resolved to In Progress

#12 Updated by Tyler Wilson over 2 years ago

  • Status changed from In Progress to Resolved

#13 Updated by Tyler Wilson over 2 years ago

The directory for testing this application can be found in:

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

#14 Updated by John Shinaman over 2 years ago

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

#15 Updated by Christopher Isbell over 2 years ago

  • Status changed from Resolved to Closed

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

Also available in: Atom PDF