Hi Matthias, >> Why don't we face the same problems with other transformations too?
We will always run into this problem, if the chosen transform is unable to correct the misalignment in physical space. Two example are: 1. a translation transform for images, that are rotated to each other in physical space 2. a 6 degree rigid transform for images, that need to be sheared in physical space in order for them to match In both cases the respective transform could be good enough to register the images in world space, because the geometry could possibly take account of the corresponding misalignment. >> What if we are doing a affine transformation in physical coordinates. As long as ITK finds the global optimum, the result will always be correct. This is because affine transform can account for all errors introduced by the World to Physical transform. Anyway, the process of finding the global optimum could be harder in physical space compared to world space and could possibly get stuck in local extrema. >> which can be only done by rotating the image data outside the application. Resampling the images could help (itk::ResampleImageFilter) >> Do you know a way of saving .pic files to .mhd? MITK can do that for you, just load pic and save to mhd. Anyway, removing the orientation matrix of the images in the mhd file will probably not solve your problem. You will get stuck in the physical coordinate system just like ITK gets stuck ;) By the way: Did you know Luis Ibanez admitted, that disregarding image geometries was one of the biggest mistakes during design of ITK? Best regards, Klaus -----Ursprüngliche Nachricht----- Von: Matthias Keil [mailto:[email protected]] Gesendet: Fr 19.12.2008 19:28 An: [email protected] Betreff: [mitk-users] [Fwd: Re: AW: AW: AW: Visualization Error afterRegistration] Dear Klaus, thanks for your fast replies! I really appreciate that. I understand the problem we have with using ITK for registration of differently oriented volumes and translations. My question is now: Why don't we face the same problems with other transformations too? What I mean is the following: If we have differently oriented volumes and do a translation in physical space the transformation to world space introduces a rotation to the moving image which has not been there (or removes the rotation which has been there, depending on the initial situation). What if we are doing a affine transformation in physical coordinates. Don't we introduce the same error to the moving image, by adding or removing the rotation to the one which had been calculated in physical space? The above would mean that you could change the code for all transformation possibilities. Unfortunately it also means that I would have to change my volumes in a way that their orientation is the same initially (by the visualization and transformation matrices), which can be only done by rotating the image data outside the application. Do you know a way of saving .pic files to .mhd? Best regards, Matthias BTW: Did you send your e-mail off the mailinglist on purpose? Fritzsche Klaus schrieb: > > Hi Mattias, > > > > thank you for being insistent here. I took some more time to think > about our approach of handling different transforms. And yes, we > actually do run into a problem in cases where P2W_F*W2P_M does more > than the transform allows. For example, P2W_F*W2P_M could introduce > rotation in cases we only want to allow for translation. > > > > The bad news now is, that there does not seem to be any way to solve > this. The ITK limitation up to the current version is, that it matches > the images in physical space. So if the images are differently > oriented in world space, a translation in ITK physical space will > never lead to the optimal solution. > > > > This restricts our registration by translation transforms to images > that have identical orientation matrices. Knowing this, I think we > could proceed along the lines you proposed: In cases of translation > transform, we could exchange P2W_F and P2W_M (because the two are > identical now, just different offsets) to correct the offset during > visualization. > > > > Best Regards, > > Klaus > > > > > > > > *Von:* Matthias Keil [mailto:[email protected]] > *Gesendet:* Donnerstag, 18. Dezember 2008 18:28 > *An:* Fritzsche Klaus > *Cc:* [email protected] > *Betreff:* Re: AW: AW: [mitk-users] Visualization Error after Registration > > > > Dear Klaus, > > I see the point that translation transformations are of a special > kind. And therefore I would suppose that they have to be treated in a > special way. > > I am not sure if a special treatment of basic transforms would > contribute to the understanding of the registration functionality. > > I think this is necessary as the registration results for translation > are wrong otherwise. > > Maybe you should try to register differently oriented images with an > affine transform to get the idea > > I tried them already and as you described the visualization problem > does not occur in this case. This must be somewhat related to the > nature of the transformation. > > Nethertheless, I think all cases should work and the visualization > (i.e. world coordinates of the moving image) should resamble the > calcualted translation. > > I am sorry if my e-mails sound criticizing. I would just like to get > the results which I expect... > > Best regards, > Matthias > > Fritzsche Klaus schrieb: > > Hi Matthias, > > > > >> What I am trying to say is that I think that the equation : > >> P2W_F*PSI*W2P_M*MOV (movingImg) "==" P2W_F*FIX2(fixedImage) > > >> Would be correct if you used P2W_M to transform the moving image > back to world coordinates. > > > > This may hold true for translation transforms like you used them so > far. The functionality covers a lot of other transforms though, e.g. > affine transforms. > > > >> This means that we are throwing away the orientation and other > information of the moving > > >> image. In my opinion this can not be the right approach. > > Yes, we try to find a new orientation in space and throw away the old > one. For some special cases like translation transforms, this could be > done differently like you proposed. > > > > Maybe you should try to register differently oriented images with an > affine transform to get the idea. I am not sure if a special treatment > of basic transforms would contribute to the understanding of the > registration functionality. > > > > Best Regards, > > Klaus > > > > > > *Von:* Matthias Keil [mailto:[email protected]] > *Gesendet:* Donnerstag, 18. Dezember 2008 14:11 > *An:* Fritzsche Klaus > *Cc:* [email protected] > <mailto:[email protected]> > *Betreff:* Re: AW: [mitk-users] Visualization Error after Registration > > > > Dear Klaus, > > thank you very much for your detailed explanation. It made some things > a lot clearer (especially the difference between MITK world and ITK > physical space. > Please let me make two remarks to your e-mail. > > First you answered to one of my questions: > > > >> My question is: Why do you have to postcompose with > > >> ItkPhysicalToWorld_(*FixedImage*)*_WorldToITKPhysical(MovingImage) > instead of > > >> itkPhysicalToWorld(*_MovingImage_*)*WorldToITKPhysical(MovingImage)? > > > > This should become clear from the above now.. We go from world to > physical and back to world. > > I agree and understood that we should go from world to physical and > back to world coordinates. But what I wanted to ask is why do we go to > the world coordinates of the fixed image although we are changing the > position of the moving image? > > What I am trying to say is that I think that the equation : > > > Composing our PhysicalToWorld transform of the fixed image we get > > > > P2W_F*PSI*W2P_M*MOV (movingImg) "==" P2W_F*FIX2(fixedImage) > > Would be correct if you used P2W_M to transform the moving image back > to world coordinates. I tried this change in the code and it did > exactly what I expected (changing the moving images position around > its initial position and no change with [0,0,0] as the calculated > transformation). I do see the point that mathematically you would have > to extend the equation with the same coefficient on both sides. Giving > us your equation. What confuses me with this approach is the following: > > We are transforming back the moving image from physical to world > coordinates by using the P2W_F transformation of the fixed image. As > you said: > > > 2) The ITK physical space, which takes into account spacing and > origin of the image but ignores its spatial direction matrix > > This means that we are throwing away the orientation and other > information of the moving image. In my opinion this can not be the > right approach. > > I hope this made my point a bit clearer. I am looking forward to your > answer. > > Best regards, > Matthias > > Fritzsche Klaus schrieb: > > Hi Matthias, > > > > Let me try to explain this differently. There are three spaces, images > can live in: > > > > The index space, which does not have spacing, origin or anything. > Coordinates in index space correspond to array indices to the image > raw data > > The ITK physical space, which takes into account spacing and origin of > the image but ignores its spatial direction matrix > > The MITK world space, which resembles the "true" space account for all > spatial information in the image header > > > > An MITK image geometry has the job to transform an image (like our > movingImg and fixedImg) from its native index space (1) to the world > space (3). Lets call the corresponding transform matrices MOV (the > geometry of the moving image) and FIX (the geometry of the fixed image). > > > > The two images, that are always displayed in world space by MITK, do > not match: > > > > MOV(movingImg) "!=" FIX(fixedImg) > > > > So our registration method should yield a result matrix PHI that > transforms the MovingImage to match the FixedImage in **world space**. > In the end, we should have: > > > > PHI*MOV(movingImg) "==" FIX(fixedImage) [Equation1] > > > > The main problem is, that our ITK algorithms all work in physical > space. So the result matrix PSI that is returned by ITK ensures only > > > > PSI*MOV2(movingImg) "==" FIX2(fixedImage) > > > > with MOV2 and FIX2 being the transforms that take the images from > space (1) to space (2). The relation > > > > MOV2 == W2P_M*MOV > > > > with W2P_M being the WorldToPhysical of the moving image, yields > > > > PSI*W2P_M*MOV (movingImg) "==" FIX2(fixedImage) > > > > In other words: two images, aligned in physical space. Composing our > PhysicalToWorld transform of the fixed image we get > > > > P2W_F*PSI*W2P_M*MOV (movingImg) "==" P2W_F*FIX2(fixedImage) > > > > And you can see from P2W_F*FIX2 == FIX and PHI = P2W_F*PSI*W2P_M, that > this exactly resembles [Equation1]. > > > > Now coming to your questions: > > > > >> My question is: Why does it have to? I do have not translation computed > > >> therefore nothing should change. > > > > Here we have the case PSI == Identity. It follows PHI = > P2W_F*Identity*W2P_M = P2W_F*W2P_M. So if W2P_M and W2P_F are not > identical, than PHI won't be identity and will be doing more than > nothing here, in your case the unexpected movement. > > > > >> My question is: Why do you have to postcompose with > > >> ItkPhysicalToWorld_(*FixedImage*)*_WorldToITKPhysical(MovingImage) > instead of > > >> itkPhysicalToWorld(*_MovingImage_*)*WorldToITKPhysical(MovingImage)? > > > > This should become clear from the above now.. We go from world to > physical and back to world. > > > > >> First why do I get a different visualization if the m_VtkMatrix does > not > > >> change? Second why does the m_VtkMatrix not change although you say > that > > >> the m_MovingGeometry is changing because of the two compositions? > > > > In the QmitkRigidRegistrationSelector.ui.h:807, you can see what I did > in order to monitor the moving geometry. This should help tracking the > changes. Just follow the information in the console output. > > > > Hope this helped! > > > > Best Regards, > > Klaus > > > > > > Klaus Fritzsche > > Dipl.-Inform., M.Sc. > > DKFZ > > German Cancer Research Center (Deutsches Krebsforschungszentrum) > > Member of the Helmholtz Association > > Division of Medical and Biological Informatics > > Im Neuenheimer Feld 280 > > D-69120 Heidelberg > > Phone: 49-(0)6221-42-3545 > > Fax: 49-(0)6221-42-2354 > > E-Mail: [email protected] <mailto:[email protected]> > > Web: www.dkfz.de <http://www.dkfz.de> > > > > Confidentiality Note: This message is intended only for the use of the > named recipient(s) and may obtain confidential and/or privileged > information. If you are not the intended recipient, please contact the > sender and delete the message. Any unauthorized use of the information > contained in this message is prohibited. > > > > > > > > > > > > *Von:* Matthias Keil [mailto:[email protected]] > *Gesendet:* Mittwoch, 17. Dezember 2008 17:24 > *An:* Fritzsche Klaus > *Cc:* [email protected] > <mailto:[email protected]>; Stein Daniel > *Betreff:* Re: AW: AW: [mitk-users] Visualization Error after Registration > > > > Hi Klaus, > > I am replying to you because I have problems understanding part 2) of > your answer. The problem is the following: > > I debugged a bit today watching the m_VtkMatrix of the > m_MovingGeometry object. Starting the registration (using translation > and Amoeba) results in the first registration transform of [0,0,0]. > Therefore nothing should actually happen. Unfortunately I end up with > a translation of the moving image. > > Therefore I do have two questions: > > You said: "even if the registration transform found by ITK does > nothing (identity transform), the image still moves". My question is: > Why does it have to? I do have not translation computed therefore > nothing should change. > > You said: "if the registration result is identity transform, the > initial moving image geometry is still postcomposed by > ItkPhysicalToWorld(FixedImage)*WorldToItkPhysical(MovingImage) and > changes" My question is: Why do you have to postcompose with > ItkPhysicalToWorld_(*FixedImage*)*_WorldToITKPhysical(MovingImage) > instead of > ItkPhysicalToWorld(*_MovingImage_*)*WorldToITKPhysical(MovingImage)? > What confuses me here are two observations: > 1. The visualization changes (which could be explained as the > MovingImage is translated to the position of the FixedImage which > would be wrong, as it would have to be translated back to its old > position. 2. Unfortunately by debugging I found out that the > m_MovingGeometry member m_VtkMatrix does not change from before and > after applying the registration translation (just by some signs). This > is confusing because of two reasons. First why do I get a different > visualization if the m_VtkMatrix does not change? Second why does the > m_VtkMatrix not change although you say that the m_MovingGeometry is > changing because of the two compositions? > > I hope that you got my point and can help me with this problem. > > Best regards, > Matthias > > Fritzsche Klaus schrieb: > > Hi Matthias, > > > > Thanks for observing this. I took a look at the problem today. You are > right, the visualization and parameter setting is confusing. For my > understanding, there are two reasons for that: > > > > Your images are shifted in z-direction in world coordinates, so the > difference shows up correctly in the sagittal and coronal plane (top > right and bottom left). Due to the rotation matrix that is given in > your images (exchanging x and z), this corresponds to z-direction in > ITK physical space. So you will have to provide a simplex delta != 0 > in direction 3. > > > > The reason for the unintuitive behavior of the visualization is, that > even if the registration transform found by ITK does nothing (identity > transform), the image still moves. You observed this initial movement > when starting the registration process. The movement originates from > the composition of the three matrices WorldToItkPhysical(MovingImage), > the registration result and ItkPhysicalToWorld(FixedImage). So if the > registration result is identity transform, the initial moving image > geometry is still postcomposed by > ItkPhysicalToWorld(FixedImage)*WorldToItkPhysical(MovingImage) and > changes. The remaining optimization steps only resemble the > optimization in physical space, which means that the translation > happens in x direction in your case although everything is displayed > in world coordinates. > > > > Concluding, you should not try to achieve a different initial > visualization, because it should already be correct. A more intuitive > visualization during the registration process would be nice, but I > cannot think of a way to do this differently. If you can, please let > me know. I hope, the new ITK release will solve most of these issues > by accounting for image geometries within the ITK registration framework. > > > > Best Regards, > > Klaus > > > > > > Klaus Fritzsche > > Dipl.-Inform., M.Sc. > > DKFZ > > German Cancer Research Center (Deutsches Krebsforschungszentrum) > > Member of the Helmholtz Association > > Division of Medical and Biological Informatics > > Im Neuenheimer Feld 280 > > D-69120 Heidelberg > > Phone: 49-(0)6221-42-3545 > > Fax: 49-(0)6221-42-2354 > > E-Mail: [email protected] <mailto:[email protected]> > > Web: www.dkfz.de <http://www.dkfz.de> > > > > Confidentiality Note: This message is intended only for the use of the > named recipient(s) and may obtain confidential and/or privileged > information. If you are not the intended recipient, please contact the > sender and delete the message. Any unauthorized use of the information > contained in this message is prohibited. > > > > > > > > > > *Von:* Matthias Keil [mailto:[email protected]] > *Gesendet:* Donnerstag, 11. Dezember 2008 13:52 > *An:* Fritzsche Klaus > *Cc:* Stein Daniel; [email protected] > <mailto:[email protected]> > *Betreff:* Re: AW: [mitk-users] Visualization Error after Registration > > > > Dear Klaus, > > sorry for being ambigous in my last e-mail. I just checked the > functionality with Simplex Delta 1 = 2 again and I have to admit that > the registration results as well as the visualization are correct. > > What confused me was the initial visualization (before starting the > registration). In my case (translation of one of the volumes in > x-direction) the inital tranlation can be seen as a left/right > difference in the transversal window. Starting the registration this > error is corrected and in the following steps the initial translation > is shown as a bottom/top difference in the sagittal window. Which is > the right visualization as my volumes are rotated. > > Is there anything I or you could do to get a good intial visualization > of the volumes? I will start with doublechecking the construction of > my translation matrix. > > Best regards, > Matthias > > Matthias Keil schrieb: > > Dear Klaus, > > last week I integrated your patch into our MITK version. Unfortunately > it did not work as expected. To be sure that it is not our problem, I > compiled the current MITK version (rev. 15933). > Using the image data I provided to you (the two rotated volumes that > are shifted by two mm) I get a visualization error. I am still using > the Amoeba optimizer and Mean Squares metric and translation. > > According to one of your e-mails I am not quite sure whether I have to > set the x or z direction simplex delta now. (There was one patch where > you mentioned that maybe I have to change the z value because of the > rotation). Therefore I tested both setting and got equal results. > > Here is my test scenario: > - the two datasets you already used > (ftp://ftp.igd.fraunhofer.de/outgoing/makeil/) > - translation > - mean squares > - amoeba with Simplex Delta 1 = 2 and Delta 2 and 3 = 0 and 10 iterations > - linear interpolation > > Even after the first iteration (where the algorithm tries [0,0,0] as > the translation vector) it seems like the coordinate system is rotated > again. Therefore the additional changes are applied to the wrong axis. > This error is indifferent from setting either Delta 2 = 2 or Delta 3 = > 2. Overall the result does not look any different from what it was > before. I could also make a small movie capturing my screen if that > helps... > > Could you please check whether the registration functionality works on > the given data in your case? Did I miss any settings that I have to > provide? > > Best regards, > Matthias > > Fritzsche Klaus schrieb: > > Hi Matthias, > > > > I have just now checked in some bug fixes to the RigidRegistration > functionality. It should now be capable of handling images of > arbitrary geometry including the datasets you sent us. > > > > Please let me now in case you run into further problems! > > > > Best Regards, > > Klaus > > > > > > Klaus Fritzsche > > Dipl.-Inform., M.Sc. > > DKFZ > > German Cancer Research Center (Deutsches Krebsforschungszentrum) > > Member of the Helmholtz Association > > Division of Medical and Biological Informatics > > Im Neuenheimer Feld 280 > > D-69120 Heidelberg > > Phone: 49-(0)6221-42-3545 > > Fax: 49-(0)6221-42-2354 > > E-Mail: [email protected] <mailto:[email protected]> > > Web: www.dkfz.de <http://www.dkfz.de> > > > > Confidentiality Note: This message is intended only for the use of the > named recipient(s) and may obtain confidential and/or privileged > information. If you are not the intended recipient, please contact the > sender and delete the message. Any unauthorized use of the information > contained in this message is prohibited. > > > > > > > > > > *Von:* Matthias Keil [mailto:[email protected]] > *Gesendet:* Dienstag, 2. Dezember 2008 14:03 > *An:* Stein Daniel > *Cc:* [email protected] > <mailto:[email protected]> > *Betreff:* Re: [mitk-users] Visualization Error after Registration > > > > Dear Daniel, > > did you find out anything of interest in the meantime? Do you want me > to help you with searching for the bug? If so and if you have any > further debugging information please let me know! As I do need a > working visualization in the registration functionality I would like > to contribute some time. > > Best regards, > Matthias > > Matthias Keil schrieb: > > Dear Daniel, > > by debugging the QmitkRigidRegistrationSelector::SetOptimizerValue > function, I found out that the transformation matrix that is build up > at the end of the function. > > At the end of this function the following lines of code are executed > after the transformation parameters are read. > > vtktransform->GetInverse(vtkmatrix); > m_MovingGeometry->GetIndexToWorldTransform()->SetIdentity(); > m_MovingGeometry->SetIndexToWorldTransformByVtkMatrix(vtkmatrix); > m_MovingGeometry->Compose(m_GeometryWorldToItkPhysicalTransform, 1); > m_MovingGeometry->Compose(m_ImageGeometry->GetIndexToWorldTransform(), 1); > m_MovingGeometry->Compose(m_GeometryItkPhysicalToWorldTransform, 0); > mitk::RenderingManager::GetInstance()->RequestUpdateAll(); > > Up to the second last line everything looks nice and as expected (the > transformation matrix in m_MovingGeometry looks right). That means if > for example a translation in x-direction was calculated the > x-translation value of the transformation matrix was changed. After > executing the line > > m_MovingGeometry->Compose(m_GeometryItkPhysicalToWorldTransform, 0); > > The changes made to the x-translation element are reset to the > original values and the z-translation element is changed according to > the value computed. > > Maybe this helps a bit. Although you probably already debugged that far. > > Best regards, > Matthias > > Matthias Keil schrieb: > > Dear Daniel, > > thanks for the information about the visualization errors. You can > download my test Datasets (actually its the same dataset twice just > slightly moved in z-direction) from our FTP server. > > ftp://ftp.igd.fraunhofer.de/outgoing/makeil/ > > I saved them in .pic format so that you can read them. > > Best regards, > Matthias > > Stein Daniel schrieb: > > Dear Matthias, > > sorry for the delay, but I was out of office and since I have implemented the > module so far no one else has answered you. I have applied your patch to my > working solution today. The manual registration sliders are working fine with > your patch, so I will commit it tomorrow. I will let you know the SVN > revision containing your patch. > > Thank you very much for contributing the patch! > > Regarding your other problem, we are currently working on some issues with > the correct visualization for every update during registration within MITK. > Maybe you can send me your testcase images, so that I can check them as well > and can try to find a solution. > > Best regards, > > Daniel > > --- > > Dipl.-Inform. Med. Daniel Stein > German Cancer Research Center > Div. Medical and Biological Informatics > Im Neuenheimer Feld 280 > D-69120 Heidelberg, Germany > Phone: (+49) 6221/42-3547 > Fax: (+49) 6221/42-2345 > http://www.dkfz-heidelberg.de/de/mbi/ > Homepage: http://www.dkfz-heidelberg.de/de/mbi/people/Daniel_Stein.html > > > > -----Ursprüngliche Nachricht----- > Von: Matthias Keil [mailto:[email protected]] > Gesendet: Mi 26.11.2008 15:48 > An: [email protected] <mailto:[email protected]> > Betreff: Re: [mitk-users] Visualization Error after Registration > > Dear MITK developers, > > it would be nice if you could give me a little update about the status > of my patch. Unfortunately I didn't get any feedback so far. > > Best regards, > Matthias > > Matthias Keil schrieb: > > > Dear MITK developers, > > > > I am working quite a lot with the QmitkRigidRegistration widget. I was > > playing around a bit with the different metrics and optimizers > > included in the functionality. I did so by decomposing a given > > translation into its x, y and z component. Registration worked out > > quite well for these easy given tasks (translating by 2 mm along each > > axis). > > > > Unfortunately there seems to be an error in displaying the > > registration results and optimization steps. I attached a .zip file to > > visualize this error. The calculations done for the registration are > > correct, as you can see from the output windows (amount of translation > > is exact and mean squares metric has value 0). The error that occurs > > is that a translation in x direction results in a translation in z > > direction in the visualization and vice versa. > > > > I think that the error must be somewhere in the following function: > > > > QmitkRigidRegistrationSelector::SetOptimizerValue > > > > which is called for each optimizer step. I do not think that this > > error is limited to the translation transform case only, but is more > > systematically. Therefore I think that something might be wrong in the > > last part of the function, where the m_movingGeometry member is > > calculated. > > > > Unfortunately I am not that experienced with the given transformations > > and changes between ITK and VTK yet. > > > > I am looking forward to hearing from you! > > > > Best wishes, > > Matthias Keil > > -- > > | Dipl.-Ing. Matthias Keil > > | > > | Fraunhofer Institute for Computer Graphics (IGD) > > | Cognitive Computing & Medical Imaging > > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > > | > > | phone : +49.6151.155.212 > > | fax : +49.6151.155.480 > > | e-mail : [email protected] > <mailto:[email protected]> > > | skype : matthias.keil.office > > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > <http://moblin-contest.org/redirect.php?banner_id=100&url=/> > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > mitk-users mailing list > > [email protected] <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/mitk-users > > > > > > > > > > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > <http://moblin-contest.org/redirect.php?banner_id=100&url=/> > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > _______________________________________________ > mitk-users mailing list > [email protected] <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/mitk-users > > > > > > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > <http://moblin-contest.org/redirect.php?banner_id=100&url=/> > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > _______________________________________________ > mitk-users mailing list > [email protected] <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/mitk-users > > > > > > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > > > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > > > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> > > > > -- > | Dipl.-Ing. Matthias Keil > | > | Fraunhofer Institute for Computer Graphics (IGD) > | Cognitive Computing & Medical Imaging > | Fraunhoferstraße 5, 64283 Darmstadt, Germany > | > | phone : +49.6151.155.212 > | fax : +49.6151.155.480 > | e-mail : [email protected] > <mailto:[email protected]> > | skype : matthias.keil.office > | web : http://www.igd.fraunhofer.de/~makeil > <http://www.igd.fraunhofer.de/%7Emakeil> -- | Dipl.-Ing. Matthias Keil | | Fraunhofer Institute for Computer Graphics (IGD) | Cognitive Computing & Medical Imaging | Fraunhoferstraße 5, 64283 Darmstadt, Germany | | phone : +49.6151.155.212 | fax : +49.6151.155.480 | e-mail : [email protected] | skype : matthias.keil.office | web : http://www.igd.fraunhofer.de/~makeil -- | Dipl.-Ing. Matthias Keil | | Fraunhofer Institute for Computer Graphics (IGD) | Cognitive Computing & Medical Imaging | Fraunhoferstraße 5, 64283 Darmstadt, Germany | | phone : +49.6151.155.212 | fax : +49.6151.155.480 | e-mail : [email protected] | skype : matthias.keil.office | web : http://www.igd.fraunhofer.de/~makeil ------------------------------------------------------------------------------ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
