Ok, I see. I can find the names of options by looking at the Slicer CMakeList or the CMake GUI. Thanks.
Good Morning @lassoan @pieper @jamesobutler @jcfr,
I was able to reduce the size of my install package by 200MB via CMake. We just want to thank you all for your help on this as we will continue to look for ways to reduce the size. If you can think of any other functions we might try to eliminate vis CMake, please do not hesitate to inform us. The smaller we can get this, the more accepting our Windows Workstation team would be willing to pre-install SlicerQREADS on all 50,000 plus systems (25,000 simultaneous users) enterprise-wide.
Thank you so much!
If you use a tool like treesize you can figure out what’s taking up space and we can tell you which parts might be optional for you depending on your needs.
Hello @pieper,
Is "scrolling the axials as they arrive " currently a functionality that I can enable?
Thanks
No, this is a new feature that would need to be enabled.
A great feature for users indeed. I know it’s just smoke and mirrors, but many (if not, most) vendors are doing it.
Thanks.
Coincidentally I stated experimenting with this the other day. As you can see in the linked video it’s super fast to read and display the images if you just read them from disk and display them so we could look at offering this preview mode while the 3D/4D inspection and processing is going on in the background.
Thanks @pieper,
Do you mean a kind of fancy progress bar that would automatically scroll through the images? That’s cool. In our situation, they’ve already previewed it in the host QREADS app that launched SlicerQREADS, so the previewing again might feel redundant.
I know what I’m about to say sounds ridiculous, but if I were to imaging the ideal UI, the axials would scroll while the coronal and sagittal slices would update to show the cross sections so far. The user would be able to see the image loading advancement in the orthogonal slices as they progress from top to bottom, and they would know that the axial series loading is complete when the cross section slices are visually full. The orthogonal slices act as progress bars if you will.
By the way, is there way to use just a regular progress bar for this. Anything to keep the user from wondering is SlicerQREADS has crashed.
Thanks
In OHIF we do the incremental fill, but not in Slicer. Yes there’s a lot of room for improving the dicom experience in Slicer, ideally optimizing for the most common cases. There are a lot of non-trivial special cases being handled by all the plugins and other mechanisms that add time to the loading.
Hold on!!! Are you guys are affiliated with OHIF?
Yes, we work very closely with the OHIF team and have for years. One of our goals is to have smooth interoperability between web and desktop applications.
Great! I’m so glad you guys are helping organizations like OHIF. Hopefully relationships like that is helping to sustain you existentially.
Thanks
How can I use a progress bar that appears when the images are loading and terminates when image loading is done?.
Thanks.
You can check out this discussion for options:
OK, is this available to use right now and is it possible to somehow sync it up with the image load process? Yet another rabbit hole? 
Thanks @pieper
I don’t think it’s a rabbit hole, but it’s just a work in progress. Right now that PR just implements the ability to look at the images as part of the metadata preview. It’s probably useful as-is but it also demonstrates that it should be possible to do something much faster in terms of presenting the images to the user. As usual it’s a SMOP* to make it happen.
* SMOP == “simple matter of programming”
1 Like
Oh, my apologies @pieper, I didn’t mean that as an offense to you guys, but to mainly my own inexperience and incompetence. It seems to takes me weeks sometimes to accomplish very simple tasks. I’ll get there eventually. Just feels like rabbit holes from my current inadequate Slicer-programming skills and lack of experience. I’m sure eventually, it will get better. 
No offense taken at all! Just wanted to set expectations with respect to that particular feature. I’m sure we’ve all spent time in “rabbitholes” or even worse chasing after bugs and otherwise spinning our wheels in unfamiliar environments.
So, to answer my question. Is this feature currently available? I would like to use the wait cursor to show progress while loading images. It would need to know how many images to expect and the current number of images loaded so far. Or is this a future feature?
Thanks
Progressive loading is not available yet.
Pre-allocation of volume and progressive loading of slices on a few threads would make a huge difference when loading the images from a remote server. However, if the images are already on the local file system (and recently accessed by QREADS) then I’m not sure it would help much.
For example, I did a quick test and importing and loading of a CT images series of 512x512x681 voxels took 8 seconds in total. 2-3 seconds were spent with importing (parse the header of 681 files and store the results in the DICOM database) and 5-6 was to load the series.
Do you use the DICOM module for loading images?
How long does DICOM import take (populating Slicer’s DICOM database with files of the selected study)?
How long does DICOM loading take (loading an image series into the scene)?