Steve,

We have discussed that turning off DICOM support in slicer is really not a good option any longer due to it's pervasive and important roll.

I would be more willing to remove the "Slicer_BUILD_DICOM_SUPPORT" than to support the an infrastructure both with and without it.

I'm willing to take on the challenge of removing "Slicer_BUILD_DICOM_SUPPORT" if you want to assign that to me.

Hans

I agree Hans - let's touch base with Jc today on this. We had a similar discussion a year or so ago when I added a dicomDatabase member to the slicer application because I think dicom is core to most slicer use cases. I don't want to encourage the style of medical imaging research that pretends you can ignore dicom :)

By doing a clean build with the option "Slicer_BUILD_DICOM_SUPPORT", the reported error won't occur. See [1]

[1] https://github.com/Slicer/Slicer/blob/e1bc774cddc410fe675bcafa390ca44412055f71/Modules/Remote/CMakeLists.txt#L32

For a already configured build tree, the problem will happen as described because the cache option "USE_DWIConvert" is not forced to any value.

To address the issue as it has been reported here, we could force the value of the option. That said, this approach would prevent the user from configuring by setting the option "USE_DWIConvert" directly since its value would always be forced.

Finally, if you consider application like Bender [1] which are based on Slicer, having the option to disable DICOM makes sense.

[2] http://public.kitware.com/Wiki/Bender/Documentation/1.1/Tutorial

Yes, makes sense.

Let's make it that BRAINSTools is automatically disabled if DICOM support is turned off.

Jc, would you mind doing this? I'm sure you know exactly how it should be done ;)

Commit r22907 move the setting of BRAINS option at the superbuild level. It means that switching option Slicer_BUILD_DICOM_SUPPORT ON/OFF will effectively set the option USE_DWIConvert and reconfigure brains appropriately.

See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=22907