Hi there! 🙂
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 26 2020
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Hi there! 🙂
Okay okay. :-)
May 25 2020
I know how to fix the obvious problem. But I want to discuss if this is the complete fix or only curing the symptoms,
@sharonYu OK. damn. Would it be possible to provide pseudonomized test data that shows the problem?
Just to be sure. Could you load one of the cleaned directories that still have a problem in the MITK DICOM Browser and check how much series are detected? Thanks.
I try these two method to solve the problem.
However, they didn't work.
May 24 2020
Sorry, did not see your claim, was already working on it. Proposed fix in D308
As we have with T27416 a mitigation strategy for the next reales cycle, I retag it as MITK general. It should be checked somewhen, but given the current needs/information, I don't think it is necessary for the next cycle.
'
But we should also discuss if we should have such an unsave construct in the class. I would judge it as premature optimization. The savest way is to over a getter that always casts the BaseData::Geometry to plane geometry and skip the unmanaed member completly. Was there an known issue, explicit plan why the current pattern was chosen?