Deleted branch from rMITK MITK: bugfix/T30213-PocoOpenSSL.

Pushed new branch to rMITK MITK: bugfix/T30213-PocoOpenSSL.

I think in doubt I would just move but not merge it for now. If we see that it is needed or wanted we can make the effort and merge it. It would be better than not offering this feature at all.

The dicom inspector has one additional dependency to module MITKDICOM. Therefore if we merge the inspector plugins also our normal inspector could only be build if DICOM module is activated. (Which it currently is per default).

In fact, this problem occurs not just for the progress bar, but the progress itself, e.g. also in the info box 1 is currently never reached even if the descriptive parameter calculation process is finished. The reason for this bug is that the progress is stored in a member variable which is updated after the progress event is invoked. Therefore, the progress variable is always lagging one update behind. This is fixed by changing the order of the called functions.
The fix is done for the descriptive parameter calculation, but also for the pixel and ROI-wise fitting.

Integrate into F1 help. Make MITK ModelFit Webpage deprecated for manual section with link to doxygen documentation.

It is a useful feature and should be part of the next release.

In T30157#253717, @fedorov wrote:

offer the feature to take an instance UID that is an int as the pixel value.

Not sure if I understand it correctly, but ... DICOM UID cannot have int as the value - this would violate VR constraints.

offer the feature to take an instance UID that is an int as the pixel value.

T29204 should be done before as we need to store the information in an appropriate way. The most important thing is that we have then a property to store the instance UID. The default UID is the pixelvalue if not overwritten by the user or another configuration. Regarding the persistance of the pixel value I see two option:
a) Leave with the fact (and document it) that DICOM Seg is not "loss less" regarding the pixel value. So after saving to and loading from DICOM Seg your label will have the same (class) name and instance UID but might have a different pixel value.
b) offer the feature to take an instance UID that is an int as the pixel value. But this is only possible if we assure in our UI that you cannot use/change into an instance UID in a Segmentation that is alrready used there by another label.
Currently I would lean to a) and generate a new ticket for b) and see if we need it in the future.