Hi,

is there a reason why e.g. interlace correlations for gradients are printed as hex float numbers? This format is used in section "Output Diffusion Gradient direction information" of the QC report as well but e.g. not in section "EddyCurrentHeadMotionCorrectIowa".

Regards,
Christina Rossmanith

Hi Christina

Are you referring to the terminal output, the report txt file or the full report xml file?

Can you provide an example?

best

Martin

Terminal output and report txt file. XML seems to be fine.

Lines look like (txt)

1 [ -0x1.a1fd9ba1b1961p-3, 0x1.45bd0e12e83a1p-5, -0x1.f4cf28c79f666p-1 ]

or (terminal)
Interlace correlation for gradient 52: 0x1.e6f854a520339p-1

I've attached a report.

Regards,
Christina

Not sure what's happening, as we have not seen that in our runs. Which system are using (mac vs linux distribution)? Which version of DTIPrep  and where did you get it from (Slicer, NITRC)? Likely this is system related and may be difficult to change.

As a work-around you could use the information from the XML, since that seems to be fine.

Martin
Originally posted by Chr. Roßmanith:

I'm using linux and the NITRC version of DTIPrep (Version: 1.2.8)

I had a look at the documentation of std::ios_base::fmtflags (cppreference.com):

"scientific: generate floating point types using scientific notation, or hex notation if combined with fixed: see std::scientific"

In src/itkDWIBaselineAverager.hxx "fixed" is used in combination with "scientific" which leads to hex notation. But it is strange why only I am hit by this problem.


Christina

My guess is that it's due to your linux distribution, as different distributions have slightly different kernels and system libraries. We usually use scientific linux, which is built on CentOS, and also compile our distributions on that platform (not sure what Slicer uses for its compilation of the extensions).

In this case, it's likely a c++ library difference. 
But, in the code the formate info for the output is not well chosen:
" << std::setw(9) << std::setiosflags(std::ios::fixed) << std::setprecision(17) << std::setiosflags( std::ios::right | std::ios::scientific )"

setw and setprecision should be aligned, particularly if one chooses a fixed notation (setw should be larger than setprecision). And if one choses a fixed notation, then one should not use scientific. So this is clearly not good programming on our end. 

The best seems to replace this with a fixed notation at the higher precision (probably too high with 17), i.e. 
" << std::setw(19) << std::setiosflags(std::ios::fixed) << std::setprecision(17) << std::setiosflags( std::ios::right)"

I'll add that as an issue to change for the next release (which though may take a while to do).

Martin