The fix was merged upstream and this task will be resolved with the merge of the current release branch this week.

Deleted branch from rMITK MITK: bugfix/T28285-Local8BitToUtf8.

Dear future assignee of this task,

In T28285#219856, @nolden wrote:

I did not dive into Windows APIs, so I just hope you know what you are doing ;)

The test looks reasonable and passes also on Linux.

One improvement could be to output the string (and maybe the hex version) in the WARNING output if the conversion fails.

And did you look into boost? There is also some conversion stuff

In T28285#219852, @nolden wrote:

I did some Googling, it seems that starting with 2019 release, Windows 10 has a UTF8 mode. It's a bit difficult to enable: "old" control panel -> region -> Administrative settings -> Change System locale -> Enable UTF8

After checking this box, MITK loads the data without code changes, but DataNode name is just a single slash "/" ... ;)

Pushed new branch to rMITK MITK: bugfix/T28285-Local8BitToUtf8.

Uh, maybe I made it more dramatic than it is. We can also do the complete opposite and stay with toLocal8Bit(). That means, that we only need conversion when writing the path and name into the properties. I wrote a Local8BitToUtf8() function and it works in a first test. We can also use it to pass an UTF-8 string to the GDCM reader. Didn't check for all code locations where to do it but its late already and tomorrow is another day. :-)

I also looked into this and one of the problems/differences to "back in the days" is that Qt nowadays assumes by default that C-strings in the constructor of QString are UTF-8 encoded. So, for example, Marco, if you change toLocal8Bit() in QmitkIOUtil to toUtf8(), you get working strings in the GUI (can be easily tested with a MessageBox::information()), but invalid strings for most of the readers, as they assume the local codepage. So we can have one or the other, but not both at the moment. The thing is that QmitkIOUtil works with QString, but mitk::IOUtil uses std::string in the structure that holds the file path (LoadInfo). This is then later used to be stuffed into StringProperty for the name property or the path property. Qt of course assumes these strings to be UTF-8 and hence we see the ?'s in the GUI.

Additional info: This is not a DICOM reader problem in the first place, as the filename string encoding seems to be unexpected (see screenshot above). Other readers work but the node still appears with a dummy symbol in the data node name.

Deleted branch from rMITK MITK: bugfix/T28271-3DInterpolation.

Diving into it, it turned out to be not that hard to fix as it was just the combination of two "bugs/missing features" that appeared to be so chaotic without knowing the interference of both issues.

Pushed new branch to rMITK MITK: bugfix/T28271-3DInterpolation.

• Rendering of the crosshair including its image planes in 3-d is done by the PlaneGeometryDataVtkMapper3D.
• Image rendering in 2-d is done by ImageVtkMapper2D.
• ImageVtkMapper2D shares its textures with PlaneGeometryDataVtkMapper3D, hence:
  • The actual image rendering is done in the instances of this 2-d mapper
  • The 3-d mapper just applies these textures to 3-d planes
• Result: everything that is rendered by the 2-d image mapper is automatically shown in 3-d as well, including binary images

Was recently removed in T28000. It just (tried to) enabled volumerendering on the segmentations. At least when the segmentation view was open to actually apply the preference. We can reintroduce the feature if we figured out to find a volume rendering setting that is actually able to show something meaningful (in v2018.04 is just got a black box). Not the best idea in the first place to be honest. If we want a good and accurate representation in 3-d we would need to create pixel-aligned surfaces out of the images.

Beware of a few things. T28211: [Image Rendering] Color change/ Opacity strange behaviour (only in Windows installers) also fixed rendering of image slices in 3-d, so I suggest to use the latest release branch to test anything related instead of the snapshot installers.

Oh, it's even simpler. I see that in DCMQI it is only float. max_digits10 is 9 for float and according to the documentation its purpose is exactly for serializing and deserializing floating point numbers without losing any precision, even though the intermediate text representation may not be exact.

@floca When DICOM says 16 characters/bytes, does it include a trailing \0 character or is it really a fixed array of size 16?

Fixed in release branch by patching DCMQI. I leave this task open as a reminder to switch back to an official DCMQI release as soon as they fixed it upstream.

Go go go!

In T28258#219286, @a178n wrote:

Hi Ralf, Stefan & others involved,
I am sorry for attracting unnecessary concerns on a bug which never really existed.

In T28262#219352, @kalali wrote:

I'd like to know why we need a duration in the first place?

Okay, back to the beginning. I still see two options that do not feel like a workaround.

In T28262#219282, @floca wrote:

In T28262#219280, @kislinsk wrote:

If we do not have any durations and just came up with the durations based on the deltas between time steps, we may want to also consider the following strategies:

• If all time steps have the same distance from each other, set the duration of the last time step accordingly
• If time steps have arbitrary durations, follow the MITK default for other cases and make it at least 1ms.

I think it is a question of philosophy. The reason why I always was and am hesitant to make up some duration, is that it is made up. We don't know it and we changing the information provided to us. We had this discussion several times in the past. And as for the dynamic modeling (e.g. perfusion) we only need to know when the frames start, it seem not right to make up things.
If the majority want's to go that way, OK.
But if I have to make something up, I would definetly picking a value that is also in hindside easier to identify as artfically added. E.g. std::numeric_traits::max or +inf.

If we do not have any durations and just came up with the durations based on the deltas between time steps, we may want to also consider the following strategies:

Why is the last timestep collapsed in the first place? Without having any context knowledge it seems to be the actual issue for me and makes not much sense as from looking at the values, it simply has a duration of 0. Is it really a flaw of DICOM or do we just come up with these values based on some other DICOM tags?

If nothing else helps, I guess the only way we can actually get closer to what happens is that you build the WorkbenchRelease configuration of the latest snapshot to be able to start the workbench in debug mode. Do you need assistance for the build?

I even extracted the same scene to reproduce your issues as close as possible but it just works for me. Can you please close the workbench, delete the DKFZ folder in %APPDATA%/../Local, and then try again? What locale do you use on your system? Maybe that's the difference.

Is there any output in the terminal window right before the crashes?

BTW, when using "Create subtask", please make sure to also check the other form fields during task creation, as they are by default set to the same values as the parent task. In particular, remove the assignee and probably some of the subscribers. :)

Also, what images did you use?

In T28000#219224, @floca wrote:

Just to be sure. How is the process of updating this task description. The person who closes a task/fixes a bug also updates the list in the Task description. Correct?

Thanks, but this is the same issue you reported yesterday. Segmentation and Multi-label segmentation share the same tools. If you test these tools on both segmentation views (cool!), I suggest to keep an eye on issues related to labels and layers other than the default ones and also different time steps in particular. For issues related to the first label in the first layer, you can verify that the issue should arise in both segmentation views.

I cannot reproduce the bug as described (and don't see it in the video), only for a specific - by the segmentation as invalid considered - last time step (like in the video).