The DICOM module must be used for loading DICOM images. It works well. It does not have this inage flipping issue.
We have not explicitly disabled ITK’s DICOM reader, but we know that it does not work well and it must not be used clinically. ITK’s DICOM reader works better when it assembles the file list by itself (instead of getting it from Slicer), but we don’t plan to investigate this much further, because the DICOM module is a much more feature-complete and robust solution anyway.
Ok, you’ve stated the problem, but I’m still not clear on the solution. I’m just getting started with knowing the Python. I have a little experience with ITK about 16 years ago when I was creating Mayo Image Studio, but I emphasize “little.”
This is urgent because, the reason I switched to Slicer was because of the orientation issues of vtkSlicerImageViewer; that’s also the reason I gave my Mayo colleagues for switching to this awesome Slicer tool kit that gets the orientations correct so I don’t have to worry about it. So, this would be a show stopper in more that one way. The 2nd way is since this is my last hoorah before retirement, if I cannot get this done, I’ll probably retire sooner. This is very important to me. I will either leave my career a hero, or and failure. Just being truthful here. Please forgive me for being so drastic and dramatic. I lost sleep over this and I’m just venting
So, what do we do in very practical cookbook steps? Remove ITK? Do we need it? Do we send the images unsorted to ITK and let it do the ordering? And what is the code for doing this? Maybe I could reorder the slices in QREADS before I send them to Slicer, but which DICOM header elements would give me the hint that these series would be a problem and need header changes or reordering.
Again, my apologies for expressing this urgency. This is probably unusual for your amazing team and I’m sure you’ll help come up with the right solution.
I’m still not clear on the solution
@spycolyf Since data are properly handled using the Slicer DICOM module (instead of directly loading the series using ITK based reader), all building blocks are available.
Mentioning this to your team is sensible I think.
Considering that the demo dataset initially shared was properly oriented using the Add Data... approach, in the interest of time the SlicerQReads prototype was built using this.
Now that we identified datasets that are incorrectly loaded using this approach, it makes sense to leverage the Slicer DICOM module.
I will submit a pull request with a draft implementation.
That said, more work will be needed to:
This is why graduating SlicerQReads from a prototype created in less than a week to an application associated with a maintenance plan will be critical.
The Add Data ... approach corresponds to the one labeled as " Non-DICOM data" in the documentation. As a shortcut and to avoid integrating with the Slicer DICOM database, we decided to use this approach. See Data Loading and Saving — 3D Slicer documentation
OK, I will explain to tell my colleagues that this is a bug that will be fixed.
Certain DICOM objects (e.g., structured reports, segmentation objects, RT structure sets) only make sense when associated series are in the database as well. So, I would recommend to clean the database when review of a new patient is started.
The fastest and most complete cleanup is creation of a new database folder (and removal of the previous one).
If reading of 4D (3D+t) data sets are not needed then the MultiVolume plugin can be disabled, to make Examine faster.
I forgot to mention that I have until the end of March to finish the implementation / coding phase and then testing starts. Is this accomplishable? I will update the tasks in GitHub. Thanks.
You can right-click on the study in the DICOM module to see the headers and confirm this is a secondary capture of some kind, not an image right off the scanner. I’m not completely clear on what QREADS is meant to support, but in my experience it’s much more common for CT scans to be reviewed from the original axials, not from a secondary capture. Is it correct that these secondary captures are merely testing data or do the represent the actual use case for QREADS?
In any case, it seems Andras, Jc, and I all agree that you should be routing the data through the dicom database so that Slicer can detect and hopefully fix any anomalies.
I’ll reiterate that the app should be heavily tested against the real expected data before deployment.
Yes, I was going to get around to studying the header. But I did notice that it was not reflected in the SOPClassUID. And it is an 8 bit secondary capture, i.e. pixels per sample = 1.
Do you think this is something that can be corrected this week? The Med school needs to use this in new student orientation on March 30th, and there is a lot of implementation and testing work that I need to do with SlicerQREADS deployment. I plan on implementing a quick and dirty on-demand SlicerQREADS extension deployment for the students in the March 30th orientation. But it is critical that the orientation is not worse than the Sankhesh’s FourPaneViewer used for the past 2 years.
Question: Management is asking if multiple SlicerQREADS instances can be launched for comparing 2 different series.
Thanks
If you load your data like this it should work for this data:
(But I also still maintain this data is very odd and not representative of real clinical data - maybe it’s just teaching data).
Yes, that’s not a problem. Be sure to use the OS level command that starts a new process and doesn’t just switch you to a currently running instance.
Or you can consider using Slicer’s CompareVolumes module.
Yes it is cadaver teaching data, but then I discovered some data that not teaching data with the same issues. I’ll study this data for that same condition. Maybe I will make it a requirement that bastardized non-DICOM compliant data is not guaranteed to work, but then the question becomes, why does the data load correctly in the other vended systems.
Question: I would expect that the database method increases the image load time, correct? Is it a significant increase?
Thanks
Oh wow! That’s cool! Most of the systems installed at Mayo have 8GB memory. Would you say this is too little memory? Or should we recommend at least 16GB to all users who want to use SlicerQREADS?.
Please forgive me for all of these Monday morning question dumps! I appreciate your responses. So far they’ve been extremely stress-relieving 
.
Anyway, one requirement is that we place patient name and number, and study and series info in the title bar. Especially important if multiple instances will be implemented and to visually detect any patient context violation issues. Is this information available when SlicerQREADS is first displayed and in time to display it in the title bar? If not, will using the database method described allow for header info access.
Another thought is that I can pass in any DICOM info via args from the DOS launch command. Would that help this as well as the orientation issue? I could pass in direction cosines and spacing between slices for orientation.
Thanks
The CompareVolumes module could be an important advance for using Slicer as a development platform. Any documentation or demos?
No worries. As you can tell, responding on this forum is something of a hobby for some of us 
Maybe just a tiny bit, but I doubt it would be noticeable if you only enable ScalarVolume support (which would make sense if that’s all you expect to be able to display, that is if you don’t expect to support timeseries volumes or something).
More memory could certainly help, but 8GB is not bad for reasonable volume sizes.
That should be no problem - just a little python code.
I don’t think this is needed, just routing through the DICOM module should be enough.
It’s a bit out of date and needs to be migrated to readthedocs, but here’s a start:
https://www.slicer.org/wiki/Documentation/Nightly/Modules/CompareVolumes
Hey @pieper,
I’ve been hesitant but, I’m going to try including this code in my qreads.py file and see what happens. We’ll see how it goes.
Question: I have a version of the SlicerQREADS extension already built. Now @jcfr has a new version ready. How shall I build the new version? Should I follow the build.md instructions again using the same target folders? Should I empty those folders first? Or should I leave the old files in tact and gitbash and build over them and maybe the build will be incremental and faster?
Thanks
Pull the latest source code using git then run make in your build folder should do it. Only the necessary parts of the application will be rebuilt, so it should not take more than a few minutes.
