I’m trying to use the converter for Siemen’s mCT data but am running into a few issues. I’ve got the prompts sinogram to be read in using the list mode sinogram header to point to a emis_00 file genereated from the e7_recon debug flag but am getting the below error when the converter gets to the normalisation sinogram.
***** oSinoModeCreation::InitNormalization() → Failed to read all data (41731200) in file ‘PATH\1.7.53.1-norm.n’ (86905 read) !
***** oSinoModeCreation::InitInputFiles() → An error occured while initalizing normalization !
***** Error while initializing input sinograms !
I’ve tried regenerating the normalisation including scatter, acf and emission sinograms but continue to get a file of the same size, 340kb, and continue to get the same error.
In the cmd line descirption of the converter I can see the -n flag is expecting a .h33 header file but I can’t seem to locate any reference to such a file, even in the debug files. The only one that half resembles this is norm3d, which I’ve tried to use with little succes.
The norm sinogram hdr says the data format is “%data format:=sinogram - expandable from norm components”.
It has the line “%axial compression:=11”. Could this be causing the lack of data? I can’t see a flag anywhere in the e7 toolbox documentation to prevent this compression.
Hi Jlawry,
The required file is the normalization sinogram generated with e7tools, not the component based file, so you need to provide the norm3d file created by the debug option. Which error do you get when you tried to use it ?
Axial compression refers to the span. By default all the correction sinograms are generated in span 11 if I remember correctly.
I believe I may have only tried having the component based norm header pointing to the norm3d file but never actually tried it with its own header, which was silly. I’m now using norm3d and its own header and the converter is now mostly working!
I am getting some strange errors still but they don’t seem to be affecting the conversion itself.
I’m using the Windows version but get errors from the converter as though it is using some Unix commands (like “mv”) and forward slashes for directory paths. Do you know if the converter uses Unix for some parts of its processes? Should I be using a Bash or a Unix-line command window? I’ve just been running it in powershell which mostly works.
Hi Jackson,
Glad it solved your issue!
If I remember correctly the converter uses some system commands for output file management when multi-threading is enabled, but the commands should be adapted to windows/linux. Do you get any error message ?
I get the following message whilst running the converter in Powershell and using just a single thread i.e. not specifying a thread value.
“C:\Users\Jackson\Desktop\convert_files>move TEST/TEST_th0 TEST/TEST.cdf
The system cannot find the path specified.”
If I manually run “move TEST2\TEST2_th0 TEST2\TEST2.cdf” (changing to a backslash) it works fine and moves the file into a cdf file which looks to contain everything I need since I managed to do a reconstruction with it.
I’ve tried specifying the output folder in quotes and not in quotes but it doesn’t seem to make a difference. Any ideas?
Further to this, I tried to use multithreading and I get an “Invalid Switch” error for a bunch of files it tries to create which seem to equal the number of threads I’ve specified. I have MS MPI SDK installed and in the PATH environment so powershell ought to be finding it if the converter needs it. Any ideas for this too?
Thanks so much for your help, Thibaut. It’s greatly appeciated.
Apologies, the development of converters is rather old now.
From what I remember, from my side, I only tested the converters using “linux-like” environments on windows (such as msys, cygwin or gitbash). These bash terminals are all using / (slash) instead of windows \ (backslash). I never tried using the powershell at the time of development, which certainly explains the problem you encountered.
About multi-threading, I would say the same, it may work using “linux-like” environments but no warranty using powershell. By the way, if I am not mistaken, multi-threading would only be of interest in case you are converting a listmode file in which you want to compute attenuation correction factos (ACFs) from a 511keV attenuation map (mumap). In all other cases, the conversion is really a matter of read/write operations so multi-threading could even be slowing down the process.