Hi,
after updating my graphics card driver to the newest available (430.39) the issue still exists. I will check on VTK side next and see if it is related to it.
Thanks,
Ingmar

Wow, that looks nice!
No, that's not what I have seen on my desktop, or a laptop or a Windows virtual machine, that used to work well with the older MITK version (2016.03.0).
I will check on a recording solution (which one did you use?) and do the same on my side...

By the way, the test system was on Windows 7!

Hi,
measurements on my side
mitk v2018.04.2 (zip downloaded from webside) with pic3d.nrrd (106.478KB), a fresh generated binary dataset and with Segmentation Add Tool (NVIDIA Quadro K5000, Full HD resolution, 60Hz refresh rate, three displays connected, Intel Xeon E5-2687w 3,4GHz (2 processors, 32cores in total), 64 GB RAM (I admit, a few years old, but still better than any standard PC ;) )
->measured with fraps
2d widgets: 20 Hz, going down over time
3D widgets: 60Hz, stable over time as no segmentation interaction is going on.

Oh, I didn't see that!!!
And it was documented in the F1 plugin manual... *RTFM*
Sorry!

After discussing this topic a bit more we now have the opinion that only showing contours for all labels would be the best solution in our opinion.
The active label then can be highlighted by a thicker contour. And this would also preserve the same workflow as in the original Segmentation plugin, right?

Hi,
I have discussed this topic with a colleague who uses the (old) Segmentation plugin a lot and now will switch to MultiLabelSegmentation plugin.
A requirement is to see the gray values of the underlying image so the segmentation can be verified. -> The red face is a no go in this case and she wants to see it as contour.
We saw that in the current implementation the other labels would dissapear then but also found a way how to get along while not changing too much:

See https://github.com/MITK/MITK/pull/188

added and signed off pull request iwegner:bug-19825-SegFault_in_IGTTrackingToolbox_pluigin

checked changes and works as it should.
With the changes no crash occurs and the following error messages are displayed in console:

We also ran into that bug! I would propose to rank that bug up as project files for us is a sensitive feature we rely on.

Added message box to mitk workbench ans till couldn't reproduce the issue. So I guess our workbench has a different startup setup than the mirkWorbench has. Thus once more decreasing severity and adapting title.

I have to add that we have a message box at the beginning of the workbench to confirm that it is not for clinical use. I can't reproduce the issue in the mitk workbench! Thus decreasing sevirity.

Hi Keno,
we currently have the case, that the old project files, that we have saved, are not compatible with the ones from 2015.05.

great! ;)

I'm confused! I have created a branch on my github fork and created a üull request
https://github.com/MITK/MITK/pull/107
This was the second trial. I have deleted the first one as it wasn't based on the v2015.05.0 branch / tag.
Anyway, you can see the easy fix above as well...

Hi,
what about the feature that we could disable the department logo by an empty path of the logo image in the system preferences?

Great and good to know. Is there a rough schedule when the feature will be finished to integrate the bugfix into the master? Or is there a way to isolate the bugfix only?
Best, Ingmar

Sure! So I have updated to the current master (96ce992e5d1e51dba0aabe1541af9a7a145d9eba) and configured and generated cmake (not a complete superbuild rebuild yet).

;) absolutely agree!
And yes, _ITERATOR_DEBUG_LEVEL would be a temp solution... but it's not that urgent.

On which system was the fix verified?
Please tell me if I can assist anyhow.
;) Ingmar

Still happens on MSVC 2013 Update 3 with MITK Superbuild and QT 5.4.

((changing status to unconfirmed on MSVC 2013 Update 3 )) as reported recently

Changes commited to
https://github.com/iwegner/MITK/tree/bug-18544-PreserveDefinedDoxygenExecutableVariable

Changes made to satify external libs that provide cmake targets and commited in branch of fork: https://github.com/iwegner/MITK/tree/bug-18540-FixExternalLibsAssumptions

Just saw that QT 5.4 RC is now available
http://blog.qt.digia.com/blog/2014/11/27/qt-5-4-release-candidate-available/

Disabling of Department logo currently not possible.

Additionaly I am not sure if setting a different logo is working as a string property "Overlay.LogoImagePath" is fetched that has never been set.

sorry for spamming, I recall the latter comment, as StdMultiWidget::SetDepartmentLogoPath can be called. Misunderstanding is, that a system preference had to be set previously with a empty string to disable the logo without having access to the StdMultiWidget. Is there a new way to set preferences to deactivate the logo when not having access to the StdMultiWidget?

Added two mitk project files. The one is howing the bug, the other one without hitting the bug. The difference between both is that layer property of child22 is set to a different value than child 11 and thus it works. The file with the bug shows double entry in OrderedNodePairs so size is 4 instead of 5. Item with layer = 101 contains two entries.

mitk project showing proper importing due to non double layer property

mitk project to show the bug

mitk project showing proper importing due to non double layer property

mitk project to show the bug

A hint: A colleague once stumbled upon this issue as well. He was confused that there was no message telling him that. He was loading an .mhd file with a different data type. So please make sure that an appropriate error message is printed and it doesn't lead to a crash.
Can't reproduce it myself currently because of timing issues...
Best, Ingmar

...besides: the current implementation also incorporates locales. So if you are on a English machine your separator will be "." and on a e.g. German machine it will be ",". This will cause an issue if you are sharing the files amongst different machines (en/de). An English machine can't read the German mps files then. Haven't checked the implementation in that direction properly but it looked suspicious to me... The proposed fix doesn't consider locales and sets it fixed to separate with ".".

In v2015.05.0 release this is still present. When you save a pointset you get only 6 values.
e.g.

<x>-7.095</x>
<y>52.2572</y>
<z>2047.83</z>

In case the coordinate has a larger number of character before the point the characters after the point are cut. Thus the precision is less when further away from the origin...

precision bug fixed in my fork
https://github.com/iwegner/MITK/tree/bug-17765-FixedCharacterSetWhenSavingPointSet
(A colleague fixed this bug by adding the precision and setting the precision to fixed.)

Hi,
no, I didn't need it, I only saw it and the api didn't make sense in the old way. If the method (float) is now gone it makes sense again...

Oh, thank you for correcting this!
I took a short look into this as well... Seems to be an issue of configuring the QTreeView class used in DataManager view. I will have the original bug in sight.

Yes, I see. Ok, I use the TOFUtils plugin, choose the created entry in the "TOF camera connection", click on Connect button and a popup come up asking if I want to specify my own camera intrinsics. (???) This is probably for camera calibration (is there a plugin for that?).
Two new nodes appear in DataManager but I don't see anything. Tests of the camera with LightVis works. How to proceed / debug?

Didn't do anything since then as I dind't have resources for it. Hardware is here but no time!

just saw, that m_SourcePlugin = MITK_TOF_PMDCAMBOARD_SOURCE_PLUGIN; refers to a #define MITK_TOF_PMDCAMBOARD_SOURCE_PLUGIN "camboardnano.W64.pap" so that in my case the wight file won't be chosen. So I will have to write my own class.

Hi, the new master works fine for activating the module. With my modifications it compiles and I currently reuse the classes from CamBoard as I would asume that they are not only equal by name (but also by implementation hopefully).
A camboard factory and a device is shown in the gui but I don't yet see images.

OpenCV needs to be enabled in supercuild in order to activate MITK_ENABLE_TOF_HARDWARE as it is a dependency for the module. This should be added to the documentation.

Hi Alex,
good to hear from you.
I already added Thomas manually as I could not change the default assinee when creating the feature request.

Sticking to documentation at http://www.mitk.org/MITK-ToF%20-%20Getting%20started
there is no option MITK_ENABLE_TOF_HARDWARE in cmake when sticking to superbuild.

By the way, not only the continuoud dart client has the problem but also the user of an installed application!

patch for feature request 16811

Not contained in 2015.05.0.
I was trying to create a new pull request but deleted it again because it was based on v2015.05.0 and should be integrated in master.
But changes are straight forward and still the same. Only the file was moved.

I have setup a branch on github to integrate into MITK if possible.

patch for feature request 16811

Hi,
I have created a github pull request of the branch
https://github.com/iwegner/MITK/tree/bug-16748-AllowingStyleSheetCustomizationInSegmentationUtilities

raising importance of the bug because this blocks customization of the plugin

Using a std::set to automatically sort the pointers during instert works fine.

rising prio to medium as it makes segmentation of a large amount of 2D slices impossible

patch fixes for QuickRenderer to compile against v2014.03.0 release

patch fixes for QuickRenderer to compile against v2014.03.0 release

As Miklos states, in the preference page it is still spelled DataManager and in plugin QmitkPointBasedRegistrationView ln 204 the iWorkbenchPart is compared to "DataManager" so the selection in data manager doesn't activate the functionality of the plugin anymore.
Reopen and quickfix?

Hi Michael and Bastian,
yes, we also discussed that way.
Having one geometry per pointset in place for faster overall manipulation in the 3d world is helpfull but when it comes to filter algorithms it is error prone in this case when the developer might only concentrate onto the points in the itk pointset within mitkPointSet and might forget about the geometry. This can be prohibited by an apropriate api (as is) but when it comes to saving the final points incorporating the positions and the geometry have to be written. I don't see a benefit to add a geometry section in the xml pointset format. The stored positions act as result. I don't see a need to reproduce working steps. The geometry would also only store one transformation and not changes over time.
Are there other opinions on this?
;) Take care and thanks for the great work,
Ingmar

image showing the discripancy between 2d and 3d views when using PointBasedRegistration Plugin

Hi,
Rostislav has published code of a feature that might be described here as "surface boundaries". So I don't open up a separate bug / feature request but add it to this bug.

That mechanism sounds very well! How much efford would such a feature be?

Hi Caspar,
one feature would be to overwrite one help page, in case the documentation needs some extension. The next example is to exclude certain help pages of modules / views that are provided by MITK but are not shown in an application.

in addition: the Image Navigator also has color around the spin boxes. Here the color should be synched with the planes color as well.

Works for me now since the latest release ;)

Hi,
when will the branch be integrated? I was working on an own Surface writer but then saw, that the writer mechanism is hard coded as well!
I would be very very interested in the integration *vote*!

ok, no errors because not contained in release 2013.09.0!!!

Hi,
tested legacy mechanism of feature branch 14866 and encountered issue with unsorted lists in mitkCoreObjectFactory.cpp 414

allWriters.merge(list2);

In debug mode, xutility throws a debug error in method _Debug_order_2 (line 744) and marks, that the sequence is not ordered.

Call stack:

	msvcp100d.dll!std::_Debug_message(const wchar_t * message=0x000007fee2520ab8, const wchar_t * file=0x000007fee202c900, unsigned int line=1295)  Line 15	C++
	Mitk.dll!std::_Debug_order2<std::_List_iterator<std::_List_val<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > > > >(std::_List_iterator<std::_List_val<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > > > * _First=0x000000000024aa08 {m_Pointer=0x000000000420d0a0 }, std::_List_iterator<std::_List_val<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > > > * _Last=0x000000000024a9e8 {m_Pointer=0xcdcdcdcdcdcdcdcd }, const wchar_t * _File=0x000007fee202c900, unsigned int _Line=1295, std::forward_iterator_tag __formal={...})  Line 745	C++
	Mitk.dll!std::_Debug_order<std::_List_iterator<std::_List_val<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > > > >(std::_List_iterator<std::_List_val<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > > > * _First=0x000000000024abe8 {m_Pointer=0x00000000042061a0 }, std::_List_iterator<std::_List_val<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > > > * _Last=0x000000000024abc8 {m_Pointer=0xcdcdcdcdcdcdcdcd }, const wchar_t * _File=0x000007fee202c900, unsigned int _Line=1295)  Line 752 + 0xae bytes	C++
	Mitk.dll!std::list<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > >::merge(std::list<itk::SmartPointer<mitk::FileWriterWithInformation>,std::allocator<itk::SmartPointer<mitk::FileWriterWithInformation> > > & _Right=[3]({m_Pointer=0x00000000042061a0 },{m_Pointer=0x000000000420d0a0 },{m_Pointer=0x000000000420c3e0 }))  Line 1297	C++
	Mitk.dll!mitk::CoreObjectFactory::GetFileWriters()  Line 414 + 0x12 bytes	C++
	Mitk.dll!mitk::CoreObjectFactory::RegisterLegacyWriters()  Line 455 + 0x1e bytes	C++
	Mitk.dll!mitk::CoreObjectFactory::RegisterExtraFactory(mitk::CoreObjectFactoryBase * factory=0x00000000041dea90)  Line 88	C++

MitkExt.dll!RegisterCoreExtObjectFactory() Line 189 + 0x6c bytes C++

	liborg_mitk_core_ext.dll!mitk::CoreExtActivator::start(ctkPluginContext * context=0x0000000003e7a070)  Line 41	C++
	CTKPluginFramework.dll!ctkPluginPrivate::start0()  Line 745	C++
	CTKPluginFramework.dll!ctkPluginPrivate::finalizeActivation()  Line 370 + 0xd bytes	C++
	CTKPluginFramework.dll!ctkPlugin::start(const QFlags<enum ctkPlugin::StartOption> & options={...})  Line 115	C++
	CTKPluginFramework.dll!ctkPluginPrivate::startDependencies()  Line 715 + 0x45 bytes	C++
	CTKPluginFramework.dll!ctkPluginPrivate::finalizeActivation()  Line 370	C++
	CTKPluginFramework.dll!ctkPlugin::start(const QFlags<enum ctkPlugin::StartOption> & options={...})  Line 115	C++
	liborg_blueberry_osgi.dll!berry::IConfigurationElement::CreateExecutableExtension<berry::IApplication>(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & propertyName="class")  Line 94	C++
	liborg_blueberry_osgi.dll!berry::Starter::Run(int & argc=1, char * * argv=0x0000000001d9b7b0, Poco::Util::AbstractConfiguration * config=0x0000000001da8b60)  Line 173 + 0x3a bytes	C++

...

Bug still is present. Reported more detailed discription in #16437.

unsorted list bug resolved in 2013.09.0 release

We are still receiving the error in the console:

provided my Miklos containing changes for true and false predicates. To be changes as suggested in latest mail.

Matt reporting on sourceforge mailing list: