ISIS3.5.00 ascii2isis runs forever on mac build
ascii2isis will generate an error if the header contains invalid data and is not skipped.
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.
#6 Updated by Ian Humphrey about 1 year 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 0%
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 about 1 year 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 0%
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.
#8 Updated by Ian Humphrey about 1 year 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 12 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.