Hi Andreas,
many thanks for the answer. I can work with this solution.
Regards,
Sandra
_______________________________________________________________________
Sandra von Sachsen, Master en Multimédia
Research Associate
Universität Leipzig | Faculty of Medicine
Innovation Center Computer Assisted Surgery (ICCAS)
Semmelweisstr.14
D - 04103 Leipzig
Germany
phone +49 (0) 341 97 - 12024
fax +49 (0) 341 97 - 12009
[email protected]
www.iccas.de
_______________________________________________________________________
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]]
Gesendet: Freitag, 17. August 2012 09:00
An: [email protected]
Betreff: mitk-users Digest, Vol 75, Issue 12
Send mitk-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mitk-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of mitk-users digest..."
Today's Topics:
1. Segmentation tools not working after reinit (Stefan D?nzer)
2. 3D-Measurement (von Sachsen, Sandra)
3. Re: Segmentation tools not working after reinit (Fetzer, Andreas)
4. Re: 3D-Measurement (Fetzer, Andreas)
5. Re: Wierd Segmentation Fault - Any ideas? (Sascha Zelzer)
6. Re: Wierd Segmentation Fault - Any ideas? (Miklos Espak)
----------------------------------------------------------------------
Message: 1
Date: Thu, 16 Aug 2012 14:37:29 +0200
From: Stefan D?nzer <[email protected]>
Subject: [mitk-users] Segmentation tools not working after reinit
To: [email protected]
Message-ID:
<cafr0uk1cyp+zgei488yjvyc-fbtz-hg+njt-8uz2wmnznff...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
we are trying to segment some MRI images using MITK 2012-06. However we are
experiencing problems on some datasets when using the segmentation plugin.
Workflows we are experiencing the problem in:
(1)
--> load an image
--> create new segmentation
--> reinit the image (align viewing planes with image planes) Adding or
--> removing per lasso masks is not possible.
(2)
--> load an image
--> create new segmentation
--> segment in rotated planes mode
--> reinit the image (align viewing planes with image planes) Adding or
--> removing per lasso masks is not possible anymore.
We are experiencing this problem only on some images.
Any suggestions?
Regards,
Stefan
"Work like you don't need the money, love like you've never been hurt and dance
like no one is watching." - Randall G Leighton
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Thu, 16 Aug 2012 14:54:54 +0000
From: "von Sachsen, Sandra" <[email protected]>
Subject: [mitk-users] 3D-Measurement
To: "'[email protected]'"
<[email protected]>
Message-ID:
<571dbe92922ea442844caacce9ed0eac08d3f...@s050003233.medizin.uni-leipzig.de>
Content-Type: text/plain; charset="us-ascii"
Hi all,
how can I measure the distance between two object points in 3D with the new
Release from June 12?
Thanks.
Best regards,
Sandra
------------------------------
Message: 3
Date: Thu, 16 Aug 2012 18:12:58 +0200
From: "Fetzer, Andreas" <[email protected]>
Subject: Re: [mitk-users] Segmentation tools not working after reinit
To: Stefan D?nzer <[email protected]>
Cc: "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Stefan,
thank for reporting this issue. I was able to reproduce this bug using the MITK
2012-06 release version. However in our current master this bug seems to be
fixed. Some time ago we made bigger changes to our image reslicing mechanism
which is also used by the segmentation. I think this solved this issue.
What you can do now is to compile MITK by using the current master. Note that
this version of MITK will be a developer version. Or you can wait until the
mid-september which is when we are planning to make our next release.
If it is not very urgent for you I would recommend to wait for the next release
which is as I said in about a month.
Regards
Andreas
On 16.08.2012, at 14:37, Stefan D?nzer wrote:
Hi,
we are trying to segment some MRI images using MITK 2012-06. However we are
experiencing problems on some datasets when using the segmentation plugin.
Workflows we are experiencing the problem in:
(1)
--> load an image
--> create new segmentation
--> reinit the image (align viewing planes with image planes) Adding or
--> removing per lasso masks is not possible.
(2)
--> load an image
--> create new segmentation
--> segment in rotated planes mode
--> reinit the image (align viewing planes with image planes) Adding or
--> removing per lasso masks is not possible anymore.
We are experiencing this problem only on some images.
Any suggestions?
Regards,
Stefan
"Work like you don't need the money, love like you've never been hurt and dance
like no one is watching." - Randall G Leighton
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
mitk-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------
Message: 4
Date: Thu, 16 Aug 2012 18:19:45 +0200
From: "Fetzer, Andreas" <[email protected]>
Subject: Re: [mitk-users] 3D-Measurement
To: "von Sachsen, Sandra" <[email protected]>
Cc: "[email protected]"
<[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Sandra,
the June release version does not support 3D measurements directly. Our
measurement plugin can only be used in a plane. What you can try to do is to
rotate one of the render windows so that the two points are lying on the
rotated plane. Then you can draw a line with the measurement plugin on this
rotated plane which should give you the distance.
I hope this answers your question.
Regards
Andreas
On 16.08.2012, at 16:54, von Sachsen, Sandra wrote:
> Hi all,
>
> how can I measure the distance between two object points in 3D with the new
> Release from June 12?
>
> Thanks.
>
> Best regards,
> Sandra
>
>
> ----------------------------------------------------------------------
> --------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions will include endpoint security, mobile security and the
> latest in malware threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> mitk-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------
Message: 5
Date: Fri, 17 Aug 2012 01:02:02 +0200
From: Sascha Zelzer <[email protected]>
Subject: Re: [mitk-users] Wierd Segmentation Fault - Any ideas?
To: "Clarkson, Matt" <[email protected]>
Cc: mitk-users <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Thanks Miklos for the analysis. I tried to fix the mentioned issues in the
following branch (details inline below):
bug-12894-fix-global-tnc-handling
It would be great if you could merge that branch into your MITK version and
tell me if you are still experiencing issues.
I essentially picked up Miklos questions about the TNC and the RenderingManager
and decided to remove the
mitk::RenderingManager::SetTimeNavigationController(...) method. Now each RM
instance owns a separate TNC and the QmitkStdMultiWidget does not create a TNC
anymore.
On 08/09/2012 11:22 AM, Clarkson, Matt wrote:
> Thanks Miklos.
>
> Just looking through some code.
>
> Each QmitkRenderWindow has its own slice navigation controller (SNC).
> QmitkStdMultiWidget uses the SNC from each render window to send
> GeometryTimeEvent, and the time navigation controller (TNC) has a "dummy"
> interaction pattern.
> QmitkStdMultiWidget calls
> mitk::RenderingManager::SetTimeNavigationController, so that the
> RenderingManager can initialize all the views within QmitkStdMultiWidget, but
> this does not allow multiple editors with multiple QmitkStdMultiWidget, or
> indeed any other widget with a TNC.
Right. Now - by default - the QmitkStdMultiWidget uses the global RM and the
TNC from the RM instance.
> However,
>
> The new mitk::IRenderWindowPart defines GetTimeNavigationController(). The
> implication is that each editor has a TNC.
Yes. With the new approach, we could also remove the
GetTimeNavigationController() method, since the TNC should always be the one
from the RM. Or we make the method at least non-virtual.
> Additionally,
>
> The QmitkAbstractRenderEditor implements GetTimeNavigationController by
> retrieving the time navigation controller from the RenderingManager, which
> for ExtApp is the QmitkStdMultiWidget TNC, but for third party apps should be
> a different one.
I would say it depends. Now, the default GetTimeNavigationController() impl.
returns the TNC from GetRenderingManager(). In the MITK ProjectTemplate, the
contributed render editor does not override anything and hence the TNC is the
global one from the global RM. With the changes in the branch above, this now
works just fine and keeps the render windows in the QmitkStdMultiWidgetEditor
and the contributed editor in sync.
> So, to my mind, each editor should be able to maintain its own render
> windows, either QmitkRenderWindow, or QmitkStdMultiWidget or another class,
> and conform to the mitk::IRenderWindowPart interface. Then views such as
> QmitkImageNavigatorView for instance would be able to correctly step the
> axial, sagittal, and coronal slice by asking for the right render window, and
> retrieving the corresponding SNC, and furthermore ask the editor for its TNC
> and step through time-steps. This would be a consistent approach for both
> QmitkStdMultiWidgetEditor, and any third party editor (eg. ours).
I agree. However, due to a lot of legacy code in MITK assuming that there is
only one RM which can be accessed by mitk::RenderingManager::GetInstance(), I
would still like to keep using the global RM in the QmitkStdMultiWidgetEditor.
At least until we know how much code really depends on that assumption.
> This means that
>
> 1. QmitkAbstractRenderEditor should not use the TNC registered with the
> RenderingManager, as there may be many editors, and many TNC within an
> application, on different Editors/Views.
> OR
> as each editor takes focus, it should tell the RenderingManager what the
> current TNC is. This means that QmitkStdMultiWidget should not do this, but
> QmitkStdMultiWidgetEditor should.
With the proposed changes, I think using the TNC from the RM in
QmitkAbstracRenderEditor becomes legitimate again.
> 2. The mitkRenderingManager can currently only manage one TNC. It should
> either manage all of them, "the current one", or none of them - depends on
> point 1.
Now, the RM manages one and only one TNC - its own.
> 3. This has implications for how you "Initialize Views" or do a "global
> re-init", as it depends on which TNC you are working with.
Yes, but the current "global reinit" code in the data manager already gets the
RM from the currently focused IRenderWindowPart.
> Any thoughts? Does my email make sense?
Perfectly. Please let me know your thoughts.
Thanks,
Sascha
>
> Matt
>
>
> On 8 Aug 2012, at 17:25, Miklos Espak wrote:
>
>> I overlooked the smart pointer thing. The StdMultiWidget uses smart
>> pointer, but the RenderingManager uses an ordinary one. So, when the
>> StdMultiWidget is being destructed it deletes the TNC, but a pointer
>> remains to it in the RenderingManager.
>>
>> Why does the StdMultiWidget create a new TNC? Would not it better to
>> use the one of the RenderingManager?
>>
>> Miklos
>>
>> On Wed, Aug 8, 2012 at 4:42 PM, Miklos Espak <[email protected]> wrote:
>>> Hi Sascha,
>>>
>>>
>>> the problem is that the StdMultiWidget assigns its time navigation
>>> controller (TNC) to the RenderingManager.
>>>
>>> This is a problem if there are more StdMultiWidgets, since the TNC
>>> of the RenderingManager will be the TNC of the "youngest" StdMultiWidget.
>>>
>>> What happens here is that our view contains a StdMultiWidget, and
>>> when we close the view then its TNC is destructed but the
>>> RenderingManager still has a pointer to it.
>>>
>>> When a new image is opened, the RM wants to set the input geometry
>>> of the TNC that has been destructed meanwhile.
>>>
>>> I don't see how it can be destructed that early, since it is
>>> referred to by smart pointers everywhere (at least I did not like else).
>>> Anyway, not the destruction is the main problem here.
>>>
>>> I added this line to the StdMultiWidget destructor:
>>>
>>> m_RenderingManager->SetTimeNavigationController(NULL);
>>>
>>> this fixes the crash, but it might cause other problems later. Could
>>> you suggest a better solution?
>>>
>>> Thanks,
>>> Miklos
>
------------------------------
Message: 6
Date: Fri, 17 Aug 2012 07:59:54 +0100
From: Miklos Espak <[email protected]>
Subject: Re: [mitk-users] Wierd Segmentation Fault - Any ideas?
To: Sascha Zelzer <[email protected]>
Cc: mitk-users <[email protected]>
Message-ID:
<CAOVq=ooh+0tcbs_hj30pfk_kkf9neka7yvz_8qz7awlsscj...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Sascha,
thank you for working on this!
The solution sounds perfect for me.
Matt!
If you want to try out the branch today, do not forget to remove my temporary
fix first. That is in the destructor of our stdmultiwidget subclass.
Or, I can take care of this next week.
Cheers,
Miklos
2012.08.17. 0:02, "Sascha Zelzer" <[email protected]> ezt ?rta:
> Hi,
>
> Thanks Miklos for the analysis. I tried to fix the mentioned issues in
> the following branch (details inline below):
>
> bug-12894-fix-global-tnc-**handling
>
> It would be great if you could merge that branch into your MITK
> version and tell me if you are still experiencing issues.
>
> I essentially picked up Miklos questions about the TNC and the
> RenderingManager and decided to remove the mitk::RenderingManager::**
> SetTimeNavigationController(..**.) method. Now each RM instance owns a
> separate TNC and the QmitkStdMultiWidget does not create a TNC anymore.
>
> On 08/09/2012 11:22 AM, Clarkson, Matt wrote:
>
>> Thanks Miklos.
>>
>> Just looking through some code.
>>
>> Each QmitkRenderWindow has its own slice navigation controller (SNC).
>> QmitkStdMultiWidget uses the SNC from each render window to send
>> GeometryTimeEvent, and the time navigation controller (TNC) has a "dummy"
>> interaction pattern.
>> QmitkStdMultiWidget calls
>> mitk::RenderingManager::**SetTimeNavigationController,
>> so that the RenderingManager can initialize all the views within
>> QmitkStdMultiWidget, but this does not allow multiple editors with
>> multiple QmitkStdMultiWidget, or indeed any other widget with a TNC.
>>
> Right. Now - by default - the QmitkStdMultiWidget uses the global RM
> and the TNC from the RM instance.
>
> However,
>>
>> The new mitk::IRenderWindowPart defines GetTimeNavigationController().
>> The implication is that each editor has a TNC.
>>
> Yes. With the new approach, we could also remove the
> GetTimeNavigationController() method, since the TNC should always be
> the one from the RM. Or we make the method at least non-virtual.
>
> Additionally,
>>
>> The QmitkAbstractRenderEditor implements GetTimeNavigationController
>> by retrieving the time navigation controller from the
>> RenderingManager, which for ExtApp is the QmitkStdMultiWidget TNC,
>> but for third party apps should be a different one.
>>
> I would say it depends. Now, the default GetTimeNavigationController()
> impl. returns the TNC from GetRenderingManager(). In the MITK
> ProjectTemplate, the contributed render editor does not override
> anything and hence the TNC is the global one from the global RM. With
> the changes in the branch above, this now works just fine and keeps
> the render windows in the QmitkStdMultiWidgetEditor and the contributed
> editor in sync.
>
> So, to my mind, each editor should be able to maintain its own render
>> windows, either QmitkRenderWindow, or QmitkStdMultiWidget or another
>> class, and conform to the mitk::IRenderWindowPart interface. Then
>> views such as QmitkImageNavigatorView for instance would be able to
>> correctly step the axial, sagittal, and coronal slice by asking for
>> the right render window, and retrieving the corresponding SNC, and
>> furthermore ask the editor for its TNC and step through time-steps.
>> This would be a consistent approach for both QmitkStdMultiWidgetEditor, and
>> any third party editor (eg. ours).
>>
> I agree. However, due to a lot of legacy code in MITK assuming that
> there is only one RM which can be accessed by
> mitk::RenderingManager::**GetInstance(),
> I would still like to keep using the global RM in the
> QmitkStdMultiWidgetEditor. At least until we know how much code really
> depends on that assumption.
>
> This means that
>>
>> 1. QmitkAbstractRenderEditor should not use the TNC registered with
>> the RenderingManager, as there may be many editors, and many TNC
>> within an application, on different Editors/Views.
>> OR
>> as each editor takes focus, it should tell the RenderingManager
>> what the current TNC is. This means that QmitkStdMultiWidget should
>> not do this, but QmitkStdMultiWidgetEditor should.
>>
> With the proposed changes, I think using the TNC from the RM in
> QmitkAbstracRenderEditor becomes legitimate again.
>
> 2. The mitkRenderingManager can currently only manage one TNC. It
> should
>> either manage all of them, "the current one", or none of them -
>> depends on point 1.
>>
> Now, the RM manages one and only one TNC - its own.
>
> 3. This has implications for how you "Initialize Views" or do a
> "global
>> re-init", as it depends on which TNC you are working with.
>>
> Yes, but the current "global reinit" code in the data manager already
> gets the RM from the currently focused IRenderWindowPart.
>
> Any thoughts? Does my email make sense?
>>
> Perfectly. Please let me know your thoughts.
>
> Thanks,
> Sascha
>
>
>> Matt
>>
>>
>> On 8 Aug 2012, at 17:25, Miklos Espak wrote:
>>
>> I overlooked the smart pointer thing. The StdMultiWidget uses smart
>>> pointer, but the RenderingManager uses an ordinary one. So, when the
>>> StdMultiWidget is being destructed it deletes the TNC, but a pointer
>>> remains to it in the RenderingManager.
>>>
>>> Why does the StdMultiWidget create a new TNC? Would not it better to
>>> use the one of the RenderingManager?
>>>
>>> Miklos
>>>
>>> On Wed, Aug 8, 2012 at 4:42 PM, Miklos Espak <[email protected]> wrote:
>>>
>>>> Hi Sascha,
>>>>
>>>>
>>>> the problem is that the StdMultiWidget assigns its time navigation
>>>> controller (TNC) to the RenderingManager.
>>>>
>>>> This is a problem if there are more StdMultiWidgets, since the TNC
>>>> of the RenderingManager will be the TNC of the "youngest" StdMultiWidget.
>>>>
>>>> What happens here is that our view contains a StdMultiWidget, and
>>>> when we close the view then its TNC is destructed but the
>>>> RenderingManager still has a pointer to it.
>>>>
>>>> When a new image is opened, the RM wants to set the input geometry
>>>> of the TNC that has been destructed meanwhile.
>>>>
>>>> I don't see how it can be destructed that early, since it is
>>>> referred to by smart pointers everywhere (at least I did not like else).
>>>> Anyway, not the destruction is the main problem here.
>>>>
>>>> I added this line to the StdMultiWidget destructor:
>>>>
>>>> m_RenderingManager->**SetTimeNavigationController(**NULL);
>>>>
>>>> this fixes the crash, but it might cause other problems later.
>>>> Could you suggest a better solution?
>>>>
>>>> Thanks,
>>>> Miklos
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat
landscape has changed and how IT managers can respond. Discussions will include
endpoint security, mobile security and the latest in malware threats.
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
End of mitk-users Digest, Vol 75, Issue 12
******************************************
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
