Bug #4596

ISIS3.5.00 ascii2isis runs forever on mac build

Added by Carina Johnson 11 months ago. Updated 7 months ago.

Target version:

ascii2isis will generate an error if the header contains invalid data and is not skipped.

Software Version:
Test Reviewer:


I have installed the new ISIS3.5.00 build on my mac (El Capitan 10.11.6) and tried running isis2ascii and then ascii2isis on an image. isis2ascii seems to work fine, but ascii2isis runs forever (as if it's in an infinite loop or something) with no error message. I tried it with both a Bennu simulated image and an MSI image of Eros.

I also have an install of ISIS3.5.00 on a RedHat7 system and ran the same images through isis2ascii and ascii2isis with no problem.


#1 Updated by Stuart Sides 11 months ago

  • Status changed from New to Acknowledged

Can you make your input data and parameters used available to me?

#3 Updated by Stuart Sides 10 months ago

  • Software Version deleted ()

#4 Updated by Stuart Sides 10 months ago

  • Target version set to 3.5.0 (FY17-patch 2017-04-07 Apr)

#5 Updated by Ian Humphrey 10 months ago

  • Status changed from Acknowledged to Assigned
  • Assignee set to Ian Humphrey

#6 Updated by Ian Humphrey 10 months ago

  • Status changed from Assigned to In Progress

Replicated Carina's issue with the following commands (on OS X El Capitan 10.11.6):

setisis isis3

cd /work/projects/isis/latest/m04596/ticketData

isis2ascii from=CW1071364100B_IU_5.cub to=CW.txt

ascii2isis from=CW.txt to=a2i.cub samples=1024 lines=1024

The ascii2isis progress is stuck at "0%."

Interestingly, if I run isis2ascii with header=no, there seems to be no issues. Maybe the header is throwing something off on the mac.

#7 Updated by Ian Humphrey 10 months ago


I've changed my input data so it does not contain any special pixel values (LRS, HRS, etc.). ascii2isis doesn't seem to like non-numerical characters in its input file

I've tested this on three operating systems with the same behavior: Fedora 21, Centos/RHEL 7, and OS X 10.11.6

The commands below will cause ascii2isis to hang:

setisis isis3

cd /work/projects/isis/latest/m04596/ticketData

isis2ascii from=EN1007907102M.cub to=EN.txt

ascii2isis from=EN.txt to=EN.cub lines=1024 samples=1024

If we change isis2ascii to have header=no, it works:

setisis isis3

cd /work/projects/isis/latest/m04596/ticketData

isis2ascii from=EN1007907102M.cub to=EN_noheader.txt header=no

ascii2isis from=EN_noheader.txt  to=EN_noheader.cub

Alternatively, if we do want the header, we can provide a SKIP to ascii2isis.

I counted the number of characters in the first line (including a character for the new line) and the number of characters in the second line (including a character for the new line) to get a SKIP value.

In this case, skip=65 didn't get stuck and provided an output cube that identically matched the input cube, EN1007907102M.cub, using cubediff.

Potential related tickets? #2253, #2066

#8 Updated by Ian Humphrey 10 months ago

Questions to consider:

How should isis2ascii be creating the output ASCII text file?

  • Right now, it outputs alphabetical characters for special pixels (NULL, HRS, HIS, LRS, LIS).

  • If header=yes (default), outputs a header that contains alphabetical and numerical characters.

How should ascii2isis expect its input data to be formatted?

  • Does ascii imply all valid ASCII characters?

  • Should it only allow numeric characters?

    • If so, how would it handle a header?
    • How would it handle special pixels?
  • Should it allow alphanumeric characters?

  • Since isis2ascii outputs a header by default.

    • Is user responsible for determining a SKIP for the header?
    • Should the offset be encoded in the header for ascii2isis to pick up?

#9 Updated by Ian Humphrey 9 months ago

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

Issue occurs because ascii2isis does not properly handle reading a file when the header generated by isis2ascii is not skipped.

The reason it hangs on OSX but not Linux is related to different implementations of the C++ library on OSX 10.9+ (libc++) and Linux's GNU C++ library (libstdc++).

When extracting data to an ifstream (and expecting a double), Linux and OSX behave slightly different when encountering certain sequences of characters.
This can cause the stream to break on OSX but not on Linux.

Added an error to inform user where the reading failed, what character it tried to read, and lets user know to skip header data in the input file.

#11 Updated by Marjorie Hahn 9 months ago

Changes look good. +1

#12 Updated by Tammy Becker 9 months ago

  • Target version changed from 3.5.0 (FY17-patch 2017-04-07 Apr) to 3.5.1 (Sprint 1)

#13 Updated by Stuart Sides 9 months ago

  • Status changed from Resolved to Closed

Closed for outside user

#14 Updated by Stuart Sides 7 months ago

  • Target version changed from 3.5.1 (Sprint 1) to 3.5.1 (2017-08-08 Aug)

Also available in: Atom PDF