`ReadCT_DICOM()` only works for slices of size 512 x 512

[mpayrits]

To demonstrate the bug, I'm attaching two sets of DICOM slices (created by importing pynrrd-generated NRRD files into Slicer and exporting them as DICOM). You can open them in Slicer or another DICOM visualization app and verify all of their CT numbers are equal to 400 (an arbitrary value) and that their slice sizes match the description in their filename. Voxel spacings are (not very realistically) 1 cm in each direction. The ramp was chosen so that the correct density is 4.0 g/cm3 and the density at a CT number of zero is 2.0 g/cm3.

To reproduce, unzip all the files to a folder and run:

ctcreate dcm100x100.input
ctcreate dcm512x512.input

Inspect dcm100x100.egsphant and dcm512x512.egsphant with a text editor. Note that the former is not homogeneous, though it should be.

The issue is the following: ctcreate allocates a 512-by-512-by-270 CT array and passes it to ReadCT_DICOM() in ReadCT_DICOM.c. ReadCT_DICOM() increments the flat index into the CT array by exactly one on each new pixel it encounters, ignoring the jumps in the flat index it should perform at the end of each row and each slice. That's why a lot of the pixels get stored into portions of the array that ctcreate does not consider further and a large part of the portion that it does consider is not touched and remains at the initial value of 0.

I've submitted a pull request #717 that addresses this. Mind you that it's a quick patch to a spectacularly hideous source file - yes, even after setting the tab to expand to 8 spaces. The duplicated code, the dead code, the duplicated dead code, the never-ending indentation, the commented-out code, the manual placement of null characters, you name it. So beyond this quick patch I think the file should be completely rewritten. It would make sense to pass the allocated CT array sizes too in case the user wants to increase them beyond the 512-by-512-by-270 default. And though EGSnrc seems to avoid external libraries, an external DICOM parsing library should really be used for an even remotely robust implementation.