Download BETTER Weasis Dicom Viewer
Cuauhtleco Scoobz
Weasis is a multipurpose standalone and web-based DICOM viewer with a highly modular architecture. It is a very popular clinical viewer used in healthcare by hospitals, health networks, multicenter research trials, and patients.
Weasis DICOM viewer is cross-platform, free/libre and open-source software (FLOSS), multi-language and allows a flexible integration to PACS, RIS, HIS or PHR. This multi-platform DICOM viewer runs on Windows, Linux, and Mac OS X. It allows high-quality renderings with high performance through the OpenCV library.
Yes, the Weasis portable version can be copied in DICOM CD-ROMs as a multi-platform stand-alone viewer with launchers for Mac OS X, Linux and Windows. The viewer requires that a Java Runtime Environment (JRE 8 or greater) be installed on the machine to run. If Java is not installed on Windows, a dialog will propose to install it from the Internet.
For burning studies with Weasis, and additionnal plugin must be activated. In the web distribution, add weasis-ext.war. In the portable distribution, 1) uncompress weasis-ext.war, 2) copy weasis-isowriter-x.x.x.jar into weasis-portable/weasis/, 3) replace the file conf/ext-config.properties, 4) edit ext-config.properties and modify $weasis.codebase.ext.url by $weasis.codebase.url
We really like Horos as it is a free open source version of the same software as that used by The Royal College of Radiologists for the viva part of the final FRCR (Part B) exam. Becoming familiar with Horos will help radiology trainees when preparing for this exam. Horos is easy to use and as a full 64-bit medical image viewer for Mac there is a huge amount of functionality contained within. It is updated regularly. We believe Horos is the best free DICOM viewer for Apple MacOS.
Interestingly, Horos is named after the Egyptian god Horus, son of Osiris and Isis. Horos is a based on OsiriX (a similar paid-for medical viewer), named after Osiris. The developers obviously appreciate Egyptian and greek mythology!
I plan to use Pseudo Color Softcopy presentation state(PCSPS) to map pixel values from grayscale space to rgb space. I don't want set the photometric interpretation in the original dicom file to 'Palette color'(it's MONOCHROME2) and add color lut to avoid editing/copying the original file(btw the above method works for getting false color images)
I created a presentation file(*.pre) with the following fields where the reference SOP Instance UID refers to my dicom file. When I load the presentation file into the weasis I can see the effects of changed Modality and VOI but color palette lut is not working, image is still a grayscale image.
My desired output is what we get when the photometric interpretation is set to Palette Color, but I'm not able to get the color image using PCSPS. Can I get the same effect using PCSPS file with the photometric interpretation set to 'Monochrome2' in the reference dicom file?
I'm running Conquest 1.4.17alpha web and it works fine. We're trying to enable a java viewer as opposed to running the viewer=serversideviewer in the dicom.ini. I've tried the configuration below but can't get the .jnlp to launch successfully.
I got basic weasis connectivity going, with these limits: you replace seriesviewer by a weasisviewer script, which starts up weasis for an individual series. Since starting weases takes quite a long time (10 s or more), it may be better to start it at study level. To do this I can:
1) start it at study level when you ask to view a series
or 2) create a new studyviewer option (requires a dgate.exe update)
or 3) create a specific weasis starter page where you query for the patient/study, e.g., dgate.exe?mode=weasisstarter
Which is preferable depends on the intended application. How do you see this? If you want to mix conquest web functions with weasis then 1 or 2 may be preferable. 3) Is good for a standalone application.
Another limitation is that weasis cannot pass bridge or address information into dgate.exe (it generates the '?' that starts the variable part of the URL itself). So weasis will only allow viewing of data for one server per conquest web system.
All that we are looking for is for some type of series viewer (definately something more that viewer=serversideviewer) to launch when the results are returned from querying PatientID or PatientName from the Conquest web.
I can get the viewer to launch if I pass all the info manually thru the URL, even from over the internet. But, obviously, the doctors will not be able to do this. They just need a viewer to be used over the internet.
Edit 1): put in that it asks for its own AE title from the server. Assumptions:
1) webscriptaddress is set correctly in cgi-bin/dicom.ini
2) The server's own AE title is in acrnema.map and has the correct IP and PORT.
3) dicom.ini in cgi-bin refers to a recent dgate.dic and acrnema.map
weasis makes a WADO HTTP connection to conquest, (using webscriptadress in the lua script), that looks like -bin/dgate.exe. If you have a HTTP connection that works externally to get to conquest, you can just substitute that in cgi-bin/dicom.ini; it must end with dgate.exe (or dgate for linux) though.
after adding correct references to dgate.dic and acrnema.map in cgi-bin/dicom.ini, things start to work for robby. Now we see the thumnails in weasis appear and then dissappear. Trying to solve that now. A similar behavior has been reported with older 1.4.16's but it should have been fixed. Does anybody have a clue?
In 2003, Horii has presented a survey of free and commercial DICOM viewers [8]. He analyzed viewing capabilities by means of supported DICOM object types, included image processing methods, and the ability to export images. Horii stated that tools, which are easy to use and include rich functionality, can also be found in the open source field.
In 2007, Nagy has published a list of suitable DICOM open source tools [9]. He included server, viewer, image processing, teaching file tools, web-based PACS, and general toolkits, which include conversion and code libraries.
Out of the 28 projects, 16 tools are licensed as open source, 8 as free, and 4 as commercial products. 15 viewers are designed as standalone, 8 as web-based, and 5 as platform-independent software. In addition, 7 tools also provide GUIs for mobile devices. Interfaces for DICOM C-STORE as SCP and SCU, as well as Q/R, are supported by 4 and 5 tools, respectively. WADO is provided by 7 and parameter transfer by 5 viewers. However, C-STORE SCP, SCU and Q/R interfaces are almost entirely offered by standalone tools. Only MIPAV as the platform-independent and Xero as the web tool support at least one DICOM interface too. In contrast, excluding OsiriX, GingkoCADx, and Weasis, WADO is only supported by web- and platform-independent solutions. In total, GingkoCADx and OsiriX supply the most interfacing possibilities. Only parameter transfer seems to not be possible with both viewers.
A total of 13 image viewing criteria have been included. Eight requirements for 2D and five requirements for 3D exist. On the average, a total of 5.89 image viewing criteria are fulfilled, 4.46 of the 2D and 1.43 of the 3D viewing criteria Concerning only standalone viewers, a mean of 4.60 and 1.67 criteria are met for 2D and 3D viewing, respectively. On the other hand, for web-based viewers, 3.50 2D and 0.625 3D viewing criteria are met on the average. With 5.60 2D and 2.00 fulfilled 3D image viewing criteria, platform-independent tools achieved the highest values here.
Our survey does not yield an overall best candidate. There is no viewer fulfilling all criteria we have defined. Each application has its own focus and requires particular features. Thus, significance is achieved by comparing the viewers with respect to use cases.
The digital imaging and communications in medicine (DICOM) protocol is the leading standard for image data management in healthcare. Imaging biomarkers and image-based surrogate endpoints in clinical trials and medical registries require DICOM viewer software with advanced functionality for visualization and interfaces for integration. In this paper, a comprehensive evaluation of 28 DICOM viewers is performed. The evaluation criteria are obtained from application scenarios in clinical research rather than patient care. They include (i) platform, (ii) interface, (iii) support, (iv) two-dimensional (2D), and (v) three-dimensional (3D) viewing. On the average, 4.48 and 1.43 of overall 8 2D and 5 3D image viewing criteria are satisfied, respectively. Suitable DICOM interfaces for central viewing in hospitals are provided by GingkoCADx, MIPAV, and OsiriX Lite. The viewers ImageJ, MicroView, MIPAV, and OsiriX Lite offer all included 3D-rendering features for advanced viewing. Interfaces needed for decentral viewing in web-based systems are offered by Oviyam, Weasis, and Xero. Focusing on open source components, MIPAV is the best candidate for 3D imaging as well as DICOM communication. Weasis is superior for workflow optimization in clinical trials. Our evaluation shows that advanced visualization and suitable interfaces can also be found in the open source field and not only in commercial products.
Aeskulap works, not great, but ok. I will try Weasis.
If you need a viewer and know how to use WINE, microdicom and Radiant Dicom viewer are much better and free. I just do not know how to use Wine yet on this Distro. I use it and those viewers on Peppermint Linux.
Weasis is a multipurpose standalone and web-based DICOM viewer with a highly modular architecture. It is a very popular clinical viewer used in healthcare by hospitals, health networks, multicenter research trials, and patients.
Flexible integration with any PACS, RIS, HIS or PHR can be done with the DICOM and DICOMWeb standard interface. It allows high-quality renderings with high performance through the OpenCV library.
Because the Orthanc project is focused on the promotion of freesoftware for medical imaging, we do not publish the list ofproprietary DICOM viewers that are compatible with Orthanc. Here is alist of free and open-source viewers that are known to be compatiblewith Orthanc (do not hesitate to warn us about other compatible FOSS):
df19127ead