- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 14 2020
Pushed new branch T22085-PerfusionConversionToConcentration-AverageBaselineSignal.
Then let's wait until we talked to the Openstack admins regarding Windows instances. If we can have them in the same Openstack project, resource requirements change anyway. If we cannot have them in the same project, we may just want to increase RAM to 160 GB to have 10 Linux build clients.
Feb 13 2020
I close this task for now. Reason:
- The problem of selecting a T1 map was identified. There is a workarround (see above) and it will be finally covered by T27043.
- The fact that the current T1 conversion can be missunderstood is covered by T27047.
- Adding an additional conversion option will be discussed by @Sara and @kompan and may spawn new tasks.
P.S. :Great :)
Regarding ressources: Say what you prefer. I'll take care. If 7 would mean, we give back CPU resources. It is no problem. CPUs can be overbooked an if we have no machine configured using the CPU it does not cost money.
Was able to (probably) completely provision Ubuntu 18.04 instances for MITK builds with a cloud-config file.
Can this be contributed to the master as is?
Feb 12 2020
OK, will look into it. If you could feedback insights regarding the master, it would be great. Thanks.
not yet in the master.
Pushed new branch T27078-Crashes_with_empty_double_ellipse.
It seems to happen in a function ConvertHistogramToMap() that does not exist any more in the current master. We should observe if the propblem still exists, if the new code is used.
At least we got a crash dump as first hint:
This crash was a subset. Currently we would have had always crashes if something went wrong with the calculation (like planar figure with no arear).
Was able to successfully connect an OpenStack Ubuntu 18.04 to Jenkins via SSH. Currently writing a cloud-config file to provision the instances for MITK.
@kislinsk Could you describe the current status?
I know. I was just talking about removing the code from our DICOMReader, that gernerates these deprecated properties. The rest could stay as is, so scene files should should not be feel an impact. And we also have the mapping code in place.
FYI: When changing/removing properties there's always the chance that old mitk scene files are suddenly incompatible as properties are stored in them. If that's an issue, property aliases may be a solution for a legacy mapping between property names.
I would close it because we have the DICOM property view for that. This view shows the DICOM properties with also the human readable name of the tag. In addition it shows the value slice and time resolved.
@thomass Is this still relevant? If yes, what do you mean with sub groups. I don't know this term from DICOM?
Pushed new branch T27118-Package.