Yes, being able to export to named files is a great idea.

Regarding the "Create a DICOM Series" module, that is included already, but can no doubt be improved. You need to select a study in the tree, then right click to get the context menu and then pick Export to Study and pick the to export. See the screenshot here:

http://wiki.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/DICOM

Oh, that's great - the export button was grayed out, and I had not tried the context menu. One issue with the context menu is that it re-runs the "Checking ..." business every time the study name is clicked, which can take time for a large study and leads to weird UI behavior (ie the context menu appears somewhere else if the mouse is moved).

At the last CTK meeting we worked on a new set of widgets to replace the tree view and that should improve the overall behavior:

http://www.commontk.org/index.php/CTK-Hackfest-May-2013#Gallery_of_Results

Regarding the export, it only lets you access the fields from the Create a DICOM Series module - hopefully that's enough for real world use, but if you see issues with that let me know.

context->'Export to study' does not work in current trunk.

Yes, that got lost along with the Delete option in when switching from the tree view to the browser tables.

Alireza and I went over the code this afternoon so maybe he can re-enable the export at the same time as the delete operation.

On a related note, I was able to open source a small script I developed a while back that implements a kind of pretty-print named file organization for dicom files [1]. It might be useful on it's own, but the code could also be used to create the export directories from the database.

https://github.com/pieper/dicomsort

This should be easy to do now that pydicom is included in the default slicer build:

https://github.com/jcfr/Slicer/commit/593642d0b7265b02354c1d7cdcf0993cffdc2914

I'm working on a comprehensive DICOM export mechanism in Slicer, see
https://www.assembla.com/spaces/slicerrt/tickets/55
This will be my primary focus for the next months (besides other work of course), so hopefully it will be ready for testing soon.

Please comment on the plans if you have additional needs.
Thanks!

Implemented, see
http://www.slicer.org/slicerWiki/index.php/Documentation/Labs/DICOMExport

Feature added in commit
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=23810
Please consult the Labs wiki page in previous comment and try exporting DICOM to local folder (by changing output directory)

@inorton: Any luck trying it?

I'm working on another right cilck context menu item for the CTK DICOM browser and was asked to add this feature in as well, see discussion here:
https://github.com/commontk/CTK/pull/587

I've used the Qt toLatin1() string converter for creating driectory strings from the DICOM metadata, is that safe enough?

https://github.com/naucoin/CTK/tree/3163-export-series-to-file-system

@nicole I'm not completely sure, but I think at the moment toLatin1 is safe, as this function is used at many places in the code for casts and conversions.
There are still issues with character coding and interpretation of patient name tags etc, so until they are being addressed, toLatin1 should be OK to use.

Andrey was worried about the undefined behaviour for certain strings, so since it's a low precision directory structure conversion, I did a straight up character replacement for anything non alpha numeric.
About to push one more commit to export studies and patients as well.

That sounds a bit over-cautious to me. Maybe we can have a default mode where it tries to write all characters except the ones that I flagged in my code dicomsort linked above, but then a more compatible option that replaces all alphanumeric characters. I think it can be confusing to people when dashes, periods, commas, and other common characters are converted to an escape sequence.

@pieper: Your code[1] replaces period and commas:
underscores = r"""+`~!@#$%^&*(){}[]/=|<>,.":' """

Options:

1. call toLatin1 to get rid of international characters, then replace the characters listed above with underscores.
   1a. call toLatin 1 to get rid of international characters, replace question marks with underscores, leave other characters alone.
2. replace all non alphanumeric characters with underscores.

The replacement strategy needs to leave the directory separators and the dashes and periods used to build up the directory paths and file names.

I'd prefer to have a single strategy to keep it simple, users can rename the directories if they wish.

[1] link for ease of finding it again:
https://github.com/pieper/dicomsort/blob/master/dicomsort.py#L99-L108

Currently using this naming convention:
targetDir +
'/%PatientName/%StudyDesciption-%StudyDate/%SeriesDescription-%SeriesNumber-%InstanceNumber.dcm'

Sorry guys I've been missing on all the action by not monitoring this issue!

1. On the issue of toLatin1(): I discouraged Nicole from using it because the documentation raised a red flag for me: "The returned byte array is undefined if the string contains non-Latin1 characters. Those characters may be suppressed or replaced with a question mark." The way I read it, the result is undefined, based on the first statement. It is not either...or in the second one. But it is probably my poor English that confused me, so I am perfectly fine if we use toLatin1().

2. I suggest that naming convention should use study date and series number before the descriptions. The reason is that it is natural to want to sort the result in case of multiple series/studies, and descriptions are more likely to be garbled than numbers/dates. For the patient name, I thought maybe it makes sense to include PatientID (no strong opinion)? I also would prefer not to include series description in the file name to keep it numbers only. Note that InstanceNumber may be missing or blank, and then we are screwed, since files will be overwritten. So I would either use the sequential number, or the instance UID as the file name.

Based on the considerations above, I suggest the naming (note I added extra directory level to separate files in series):

%PatientID-%PatientName/%StudyDate-%StudyDesciption/%SeriesNumber-%SeriesDescription/%SOPInstanceUID.dcm

or

%PatientID-%PatientName/%StudyDate-%StudyDesciption/%SeriesNumber-%SeriesDescription/<sequential file number within the series formatted to %06d>.dcm

@pieper, @pinter: what do you think? Let's try to close this topic. If you have strong opinions about any of the above, please suggest an alternative. We need to move on to other things.

Seems fine to me !

@fedorov: for the sequential file number, did you mean to use the file name from the original database file?

No, when I said "sequential file number", I meant if we have 10 files in the series, we will name them 000000.dcm, 000001.dcm, ..., 000010.dcm.

correction ... the last one should have been 000009.dcm ;)

I was worried that I wasn't going to get the files in the scan order, but they do contain that information in the dicom headers so it should be reconstructable, correct?

I would not worry about this. The user should not rely on ordering of slices by file name for volume reconstruction.

Okay. I'm currently generating paths that look like this:
05223-0502-00027-05223-0502-00027/20090320-PET^1_PETCT_WB_AC (Adult)/4-PET WB
for a test volume where the patient name and ID are the same.

This is fine by me.

Directory and file name changes pushed to my CTK topic branch:
https://github.com/naucoin/CTK/commit/d2e2d69e9bd23c7c74a4fb59b9a0d97479046bbd

Any other feedback before I squash, rebase and do a pull request?

Can I stop by to see a demo? I don't have time to make a custom build of Slicer to test this.

Sure, before 12:30 or after 1:30 would work.

Feedback based on the demo:

1) use sequential numbers for file names, to avoid over-write
2) give visual notification to the user in case export failed
3) show popup box indicating that export is in progress instead of freezing the main app

Done, squashed and rebased:
https://github.com/naucoin/CTK/commit/accb8df91b86092e13d6c64f58aa7dec3ad91ffa
Rebuilding from that repo inside of Slicer then if that's fine will do a pull request on CTK.

Pull request:
https://github.com/commontk/CTK/pull/610

Had some discussions with Steve and JC about recovering gracefully from failures, having options for the export directory structure, but those will get pushed to the next version of the export. Pull request integrated in CTK:
https://github.com/commontk/CTK/commit/5f581323b6526caf5ff293d9a810a3c9f68343d9
Pull request to update CTK version in Slicer:
https://github.com/Slicer/Slicer/pull/383

Slicer pull request intgrated:
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=24654
https://github.com/Slicer/Slicer/commit/866fdcc9d3c85e6b7483f1a6d419051b71b34921