Don’t believe I do, no.
This could also work fine for the local environment, for about the same amount of work.
No, we were thinking it would still run on the client machine, but controlled by QREADS via an agreed communication protocol. Running on the server adds more trouble than it’s worth I think.
Either with the web or file based approach @spycolyf you’ll need to map out the interactions you want Slicer to be able to support and come up with a small python script to implement them.
The best way to do this I think would be via web request. I do have a little experience in that area. Other’s on the team have more, so not a problem. No problem with QREADS sending local web requests. This way, QREADS will be able to continue to run simultaneously with QREADS slicer. However, we will have to manage patient context. We can’t have images displayed in SlicerQREADS that does not belong to the current patient in QREADS. That could cause a sentinel event.
So, that begs the question, which way is safest for the patient?
Ok, so I feel that I’m establishing a clearer direction in which to focus my energies. In either case, would you agree that I will have to study Slicer development? And where should I start my focus? Is this a Python level effort, C++ level, or both?
FYI: here is the command to run SlicerQREADS:
SlicerQReads.exe --python-code “folder=‘S:\SlicerQREADS\TestImageVolumes\TestICTHead_Compressed’; import os; slicer.util.loadVolume(folder + ‘/’ + os.listdir(folder)[0], {‘singleFile’: False})”
Good morning all, and thank you for your help with everything so far. The Mayo Clinic will definitely benefit from your amazing service and we in the 3D image software development community are fortunate to have you as a resource and to be able to contribute to the community as well.
This morning, I’ve been given my march orders: Get the Slicer installation size down significantly so that QREADS installation will not increase by more than 250%. Currently, the size of a QREADS installation is about 25 to 30MB. Slicer’s size adds another 700+ MB. What is the best way to approach this issue? Should I use the process of elimination by excluding libraries 1 by 1 until it breaks, or is there a more efficient and methodical way to accomplish size reduction? Maybe there’s a way to accurately determine slicelet dependencies. And hopefully, by reducing the size, this along with other methods, will also help reduce Slicer launch times. Thanks.
According to this Slicer documentation, the footprint size and launch time can be drastically reduced as described at the bottom of that page. Do you think we could achieve a reasonably small size and launch time with the method described? …
https://www.slicer.org/wiki/Documentation/Nightly/Developers/Slicelets#Slicelet_examples
In the above response, you mentioned “investing resources.” Are you suggesting that the process would be very expensive and time consuming? And @jcfr, I think you said that you had done some size reduction already. If so, how much more reduction do you think could be done to SlicerQREADS?
Thanks
As far as I remember, you told QREADS is a Java application, so it cannot be only 30MB, because the Java runtime itself is between 70-90MB. So, the actual install size is 100-120MB. Anyway, if you are only allowed to add a few ten MB to the install package then probably the best is to only add a launcher to QREADS. The launcher would download the application from a server to a cache folder (so that it does not have to be re-downloaded at each launch). The launcher could also manage automatic updates, keeping Slicer running in the background, etc. The launcher functionality can be either built into the QREADS application or be a small standalone application.
The application package size could be probably brought down to about 400MB (removing QWebEngine, SimpleITK, all unneeded modules) without reengineering. By removing Python, it could be possible to get the install package size to about 200-300MB, but most DICOM readers are implemented in Python, so that would require porting DICOM plugins to Python (or restricting yourself to only basic 2D and 3D read images from DICOM - no DICOM RT information objects, transforms, 4D volumes, etc.). Static linking could probably reduce the package size by an additional 50-100MB, but that would again require some engineering work. Since you download hundreds of megabytes from the image server anyway, I don’t think that it is worth the effort to remove Python. Static linking might be considered, because it not just decreases package size but may also reduce startup time a lot.
Thank you for your response Andras. OK, when we install QREADS on the many PCs, the Java runtime is already installed because it’s part of the standard initial Mayo configuration of all PCs. Therefore, for a QREADS deployment, all that is needed is to copy the QREADS jar files and some dlls. It’s about 27 MB when when do a QREADS deployment. And yes, we do use a launcher that manages automatic QREADS updates, so SlicerQREADS would be also included in those updates. My team lead wants to minimize the time the user experiences to start up QREADS when there is a new deployment. But I understand, I think since we probably won’t be updating SlicerQREADS as often as QREADS, we should have separate launcher code for SlicerQREADS that detects new versions and updates.
With that in mind, maybe there’s a way to perform incremental SlicerQREADS updates after the first install. The initial installation could include Python, and many of the needed libraries, but when a modification is made to SlicerQREADS, only the modified files are copied.
Let’s keep this discussion going. I need to give the team a final statement on this Thursday afternoon.
A good workflow could be to only install/update SlicerQREADS on request, when the user launches a feature that requires it. If Slicer is downloaded then it would be kept in a cache or temporary folder, so next time it would be already there.
Partial updates: Some granularity is already built in, as Slicer core is one big package, and each extension is a small separate package. You can install/uninstall/update extensions without touching Slicer core. If there are specific features that are changing quickly then they could be developed as extensions and can be updated very quickly. However, I would expect that at the beginning we’ll often need Slicer core updates, because we’ll need to improve core features.
@spycolyf can you list the core functional requirements for SlicerQREADS? This will help identify how much code is actually strictly needed out of the Slicer install.
OK, JC can be of great help here. He is very familiar with all of the functionality as he was a major contributor to the current project and knows the low level dependencies. Also, I would be willing to cut back on some of the nice features that JC included if it reduces the size significantly. In the meantime, I will get you the functional requirements ASAP.
@jcfr, could you chime in here?
Thanks.
Some of us chatted about this during the developer hangout earlier today. Some of the most valuable parts of Slicer are also pretty demanding in terms of disk space. Even with a lot of trimming and it’s unlikely Slicer will get down below a few hundred megabytes. If that’s not viable for the Mayo software distribution model you may need to rethink things.
What about the model @lassoan suggested where Slicer is optionally installed on-demand to users who need it. This would mean having an installer as part of QREADS that would download a few hundred megabytes of Slicer binary into a cache that could be re-used quickly after the first install.
Thanks @pieper,
Yes, @lassoan suggestion has been a consideration in the past. The size issue will only make a difference in whether we distribute it to all 25,000 PCs or we give the user the option to install or not. If the size were small enough, every user would see the menu choice in QREADS to view the MPR interface. This would be great for discovery. Sorry if I’m too pushy about things; I was just told to pursue the possibility by my team lead and I need as much info as possible for the big Oversight Committee meeting next Thursday Mar 4th. Anyway, we will get the size down as much as possible and we will decide how we will deal with it.
I am currently studying the code to make the last needed changes that I will be demonstrating to the committee. It’s slow, but I think I’m getting through it.
I’m currently in the QREADS.py code. So, wish me luck. 
You can add the shortcut to all workstations. When users start the feature, the launcher shows a progress window, asking users to wait for a few minutes, and that’s it. I would not mind waiting a few minutes for some software to install or self-update time-to-time, especially if it does not block me from working something else in the meantime.
The feature is started from a java DOS shell process command issued from QREADS when the user selects the “3D MPR” menu item in the right mouse button menu of the displayed image. QREADS passes the DICOM folder path and then SlicerQREADS pops up with the selected images loaded. To the user, SlicerQREADS is a modal or nonmodal pop-up window and feels like a part of QREADS. The menu item won’t be enabled is SlicerQREADS is not installed. If we are able to get the size down enough, all users will be able to experience SlicerQREADS with out having to install it. That would be nice, but maybe not possible.
Just for reference, Acrobat Reader on my windows machine takes over 380MB and all it does is documents. A few hundred more meg to get a 3D medical image system seems more than fair 
This can all work beautifully then, for all users, without preinstalling anything large on the users computer.
We just need to create a “launcher”, which would either be a new class in QREADS implemented in Java, or a 5-10MB statically-built Qt application (that is bundled with QREADS package). This component performs the followings:
Let’s not block QREADS while SlicerQREADS is running (make it a non-modal popup) to make sure we never force the user to wait.
OK great. The Arizona Medical school has been using my modifieds version of Sankhesh’s 2018 FourPanesViewer to teach for the past 2 years and have requested a non-modal launch so that they could contiue to do other things in QREADS. So they will be happy. I will need to work out cases where the user happens to change patients while SlicerQREADS is launching a with a series from the previous patient. There can never be a time when SlicerQREADS and the QREADS host are displaying images from different patients. That another sentinel event potential.
Thanks everyone and good evening.
Good morning all,
I hate to keep beating on a dead horse, but I have a totally hypothetical scientific question. Theoretically, if I were crazy enough and had a million years to go through all of the SlicerQREADS files and eliminate 1 at a time and then test the app for failure, using the process of dependent file elimination, might I be able to get the size down significantly smaller than 300MB? Sankhesh’s 2018 FourPanesViewer app was has a total size of 60MB and had similar functionality. It was a quick install.
The typical path is to build an installer like we do for download.slicer.org that is basically a single-file archive that also sets OS configurations. But Slicer doesn’t strictly require an installer, and you could just make a zip file of the installation directory that can be unzipped on the machine for use.
Putting the installation directory on a fileshare can also work, but there will be tradeoffs since a lot of the files will be accessed over the network at startup and performance may suffer (you could test how bad this is).
Probably not all 25,000 PCs need 3D visualization, so probably it’s best to keep the installer on the shared drive and only install the app once on each PC that needs it. So you would have the download/install cost once for that machine, but then more rapid startups after that.
Thanks @pieper, @lassoan @jcfr @jamesobutler and
We appreciate your patience and willingness to work with us. The QREADS team will discuss our options and other experts on the team may chime in with technical questions beyond my experience and expertise.
Doug