Weasis | DICOM viewer available as a desktop application | Messaging library

by nroduit Java Version: v4.1.1 License: Non-SPDX

X-Ray Key Features Code Snippets Community Discussions(2)Vulnerabilities Install Support

kandi X-RAY | Weasis Summary

Weasis is a Java library typically used in Messaging applications. Weasis has no bugs, it has no vulnerabilities, it has build file available and it has low support. However Weasis has a Non-SPDX License. You can download it from GitHub.

The master branch contains Weasis 3.x.x (requires Java 8+) and the old branches are 2.5.x, 2.0.x (Java 6+) and 1.2.x (Java 6+). See How to build Weasis.

Support

Quality

Security

License

Reuse

Support

Weasis has a low active ecosystem.

It has 548 star(s) with 237 fork(s). There are 51 watchers for this library.

There were 2 major release(s) in the last 12 months.

There are 31 open issues and 314 have been closed. On average issues are closed in 286 days. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of Weasis is v4.1.1

Quality

Weasis has 0 bugs and 0 code smells.

Security

Weasis has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

Weasis code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

Weasis has a Non-SPDX License.

Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

Reuse

Weasis releases are available to install and integrate.

Build file is available. You can build the component from source.

Installation instructions are available. Examples and code snippets are not available.

Weasis saves you 95447 person hours of effort in developing the same functionality from scratch.

It has 114723 lines of code, 7757 functions and 871 files.

It has high code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi has reviewed Weasis and discovered the below as its top functions. This is intended to give you an instant insight into Weasis implemented functionality, and help decide if they suit your requirements.

Load the properties .
Overrides the slider action to show a slider .
Create the missing series
Called when a series is pressed .
Reads graphic annotation .
Builds a graphic from a given attributes .
Initialize Dose
Extracts all auto - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - and - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
draw the histogram pane
This method initializes mainPanel

Get all kandi verified functions for this library.

Weasis Key Features

No Key Features are available at this moment for Weasis.

Weasis Examples and Code Snippets

No Code Snippets are available at this moment for Weasis.

Community Discussions

Trending Discussions on Weasis

Limiting DICOM tags

What softcopy presentation state should be used?

QUESTION

Limiting DICOM tags

Asked 2020-Jun-11 at 18:27

I am trying to limit the DICOM tags, which are retained, by using

...

ANSWER

Answered 2020-Jun-11 at 18:27

The group 2 tags you are seeing are meta data tags, that are always written while writing the dataset. Unless "regular" tags, which start with group 8, these group 2 tags do not belong to the dataset itself, but contain information about the encoding/writing of the dataset, like the transfer syntax - more information can be found in the DICOM standard, part 10. They will be recreated on saving a dataset to a file, otherwise, the DICOM file would not be valid.

About the rest of the tags I can only guess, but they are probably written by the software because they are mandatory DICOM tags and have been missing in the dataset. StudyDate is certainly a mandatory tag, so adding it if it is missing is correct, if the data is seen as derived data (which it usually is if you are manipulating it with ITK). I guess the other tags that you didn't mention are also mandatory tags.

Someone with more SimpleITK knowledge can probably add more specific information.

Source https://stackoverflow.com/questions/62330774

QUESTION

What softcopy presentation state should be used?

Asked 2020-May-07 at 06:35

My aim is to add some annotations (for example, lines, arrows, shapes, or textual annotations) to a DICOM image with an opportunity to hide them and bring back when needed.

I have found two ways to accomplish it. One is to use the Overlay Plane module, but it does not fully satisfy our needs as our software requires annotations to be color. So I found another opportunity: different kinds of Softcopy Presentation State IOD-s.

As much as I understand by now, Grayscale Softcopy Presentation State IOD is most widely used. However, the word "grayscale" confuses me. Despite it is grayscale, the Graphic Annotation module contains attributes to pass information about the color of annotations, for instance, Text Color CIELab Value and Pattern On Color CIELab Value.

There are also other Softcopy Presentation State IOD-s: Color Softcopy Presentation State IOD, Pseudo-color Softcopy Presentation State IOD, and others.

Using Grayscale Softcopy Presentation State IOD I have created a presentation state file (with the .pre extension). I have tested it with Weasis DICOM viewer and it worked fine. All needed annotations were in the right places and almost all colors were right.

Now I am searching for information on how .pre files could be passed to a hypothetical PACS server, but it is not the topic of my post. Here I found the next information:

The grayscale softcopy presentation state refers to the grayscale image transformations that are to be applied in an explicitly defined manner to convert the stored image pixel data values in a Composite Image Instance to presentation values (P-Values) when an image is displayed on a softcopy device.

The color and pseudo-color softcopy presentation states refer to the color image transformations that are to be applied in an explicitly defined manner to convert the stored image pixel data values in a Composite Image Instance to Profile Connection Space values (PCS-Values) when an image is displayed on a softcopy device.

So I am a little bit confused. What kind of softcopy presentation state should be used in this situation?

...

ANSWER

Answered 2020-May-07 at 06:35

The word "Grayscale" and "Color" refer to the images handled (i.e. referenced) by the presentation state object. Apart from vector graphics that you are aiming at, the presentation state also defines (among other aspects like shutters, 2D transformations etc.) the transformation of pixel values stored in the DICOM object to so-called P-Values which can be considered as display-independent intensity values which can be displayed on a calibrated device. This obviously depends on the format of the pixel data in the source objects, i.e. Grayscale/Color.

So the choice of the presentation state object you want to use solely depends on the type of images it is supposed to handle.

Source https://stackoverflow.com/questions/61636552

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install Weasis

The master branch contains Weasis 3.x.x (requires Java 8+) and the old branches are 2.5.x, 2.0.x (Java 6+) and 1.2.x (Java 6+). See How to build Weasis.

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

Find more information at: