[Insight-users] Re: A 3D image testing
Luis Ibanez
luis.ibanez at kitware.com
Fri Dec 17 18:36:54 EST 2004
Hi Jose,
Yes, I think that the Evolutionary optimizers are
better suited than the Gradient-descent ones for
dealing with noisy image metrics such as Mutual
Information.
Benchmarking optimization is hard to do in a fair
way. For the same reason that Segmentation and
Registration methods can not be compared in a fair
way: They have parameters.
You can take any optimizer and make it behave poorly
if its parameters are not selected correctly. In order
to compare two optimizers you will have to fine tune
their parameters until you get the best out of each
optimizer. Then you could compare their outcome.
For reference on the OnePlusOne Evolutionary
optimizer you may want to look at the Doxygen
documentation for this class
http://www.itk.org/Insight/Doxygen/html/classitk_1_1OnePlusOneEvolutionaryOptimizer.html
It will point you to the following articles:
"Parametric estimate of intensity inhomogeneities applied to MRI" Martin
Styner, G. Gerig, Christian Brechbuehler, Gabor Szekely, IEEE
TRANSACTIONS ON MEDICAL IMAGING; 19(3), pp. 153-165, 2000,
(http://www.cs.unc.edu/~styner/docs/tmi00.pdf)
"Evaluation of 2D/3D bias correction with 1+1ES-optimization" Martin
Styner, Prof. Dr. G. Gerig (IKT, BIWI, ETH Zuerich), TR-197
(http://www.cs.unc.edu/~styner/docs/StynerTR97.pdf)
I would not be too concerned for finding papers stating that
"stochastics or meta-heuristics" optimizers are an accepted
practice for image registration.
Good working methods don't usually look good in a paper,
and viceversa. Papers with heuristics tend to be filtered
down in the peer-review process since reviewers don't have
access to the source code, and cannot run the methods themselves.
Reviewers are therefore limited to form an opinion on the method
based on it appearance and whether it "makes sense". There are
many heuristics that are counter-intuitive, and even more that
are imposible to evaluate without having a direct hands-on
experience with the code.
The best thing that you can do in order to get evaluate how
good or bad the methods are, is to use the
"real scientific method"
which is:
"to run an experiment yourself"
Simply try the examples:
Insight/Examples/Registration/
ImageRegistration11.cxx
ImageRegistration14.cxx
ModelToImageRegistration1.cxx
"I hear and I forget.
I see and I believe.
I do and I understand."
Confucius
Please let us know if you have further questions,
Thanks
Luis
---------------------------
jose santamaria wrote:
> Hi Luis,
>
> If I have readed quite well...Do you recommend the use of
> a stochastic optimizer for better achieving the local
> maximum of the MI metric? Have anyone realiced a
> benchmark of each ITK optimizer method to compare their
> performance?
>
> The OnePlusOneEvolutionary optimizer comes from some
> research paper? If it is, could you send me its
> reference to have a more global understanding on
> how it works?.
>
> And the last thing for everyone who has any knowledge
> in the field of registration optimizer methods...Is nowadays
> the stochastic- or metaheuristics-based optimizer an
> accepted and suitable proposal for the registration
> community? Anyone could send me any references about
> multi-modality image registration where an stochastic
> framework was used? Or a review about it if there was...
>
> nothing at all and thanks,
>
> Jose
>
> P.D.: Sorry about my poor english :-)
>
>
> El mié, 15 de 12 de 2004 a las 02:00, Luis Ibanez escribió:
>
>>Hi George,
>>
>>Thanks for your detailed message.
>>
>>I agree with you that the problem seems that to be
>>the optimizer being trapped in a local maximum
>>(since for MI you should be maximizing).
>>
>>The fundamental problem here is that Mutual Information is
>>itself quite noisy... However you can try a combination
>>of the following things:
>>
>>
>>1) Increase the learning rate of the optimizer,
>> so it has better chances to advance up to the
>> global maximum.
>>
>>
>>2) Smooth the images before passing them to the
>> registration. That should help to smooth the
>> metric.
>>
>>
>>3) You may want to consider replacing the optimizer
>> with the OnePlusOneEvolutionary optimizer, which
>> is more appropriate for noisy and stochastics
>> cost functions such as Mutual Information.
>>
>>
>>Please let us know if you find difficulties fine
>>tunning the parameters of the registration.
>>
>>
>> Thanks
>>
>>
>> Luis
>>
>>
>>
>>--------------------------------
>>Li, George (NIH/NCI) wrote:
>>
>>
>>>Luis and Jim:
>>>
>>>I tried a few things about the 3D image registration, using Mattes's MI
>>>algorithm with modification of ITK samples discussed previously. I used an
>>>identical image for both fixed and moving images, exception a translational
>>>shift of (5,5,5) on the origin of the moving image. I expected that MMI will
>>>generate a result somewhere close to the initial shift, but got (4.99, 4.64,
>>>2.83) for the final result with metric value of -0.4802. If there is no
>>>shift the metric value should be -0.4956, without any iteration.
>>>
>>>Is this because the optimization is trapped into a local minimum? Any
>>>thought on this?
>>>
>>>George
>>>
>>>FYI, if a release build is made from MFC compiler, the imageSeriesReader
>>>seems having trouble to load the image properly. But, for now, I can live
>>>with the debug build as long as it works OK.
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
>>>Sent: Monday, December 13, 2004 12:11 PM
>>>To: Li, George (NIH/NCI)
>>>Cc: Insight-users at itk.org
>>>Subject: Re: [Insight-users] GDCM is in CVS version of ITK
>>>
>>>
>>>
>>>Hi George,
>>>
>>>
>>>ITK 1.8 has support for GDCM but using it as an external library. This means
>>>that with ITK 1.8 you have to download and install GDCM independently.
>>>
>>>
>>>ITK-CVS on the other hand, has incorporated GDCM directly into the
>>> /Utilities subdirectory. We will *STRONGLY* recommend you to use the CVS
>>>version of ITK if you are interested in using GDCM for DICOM writing.
>>>
>>>
>>>Please let us know if you have further questions,
>>>
>>>
>>> Thanks
>>>
>>>
>>> Luis
>>>
>>>
>>>--------------------------
>>>Li, George (NIH/NCI) wrote:
>>>
>>>
>>>
>>>>Luis:
>>>>
>>>>I am using ITK1.8.0, and found itkGDCMSeriesReadImageWrite.cxx.
>>>>However, gdcmHeader.h is not found. Is 1.8.0 recently enough?
>>>>
>>>>George
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
>>>>Sent: Friday, December 10, 2004 4:38 PM
>>>>To: Li, George (NIH/NCI)
>>>>Cc: 'insight-users at itk.org'; 'Miller, James V (Research)'
>>>>Subject: Re: [Insight-users] RE: Error: jointPDFSum == 0!
>>>>
>>>>
>>>>
>>>>Hi George,
>>>>
>>>>You can write DICOM files from ITK by using the
>>>>GDCMImageIO class that was recently added to the toolkit.
>>>>
>>>>You may want to look at the example in
>>>>
>>>> Insight/Testing/Code/IO/
>>>> itkGDCMSeriesReadImageWrite.cxx
>>>>
>>>>Note that you can only write DICOM *IFF* you read
>>>>the image from a DICOM file first.
>>>>
>>>>
>>>>Regards,
>>>>
>>>>
>>>> Luis
>>>>
>>>>
>>>>
>>>>--------------------------
>>>>Li, George (NIH/NCI) wrote:
>>>>
>>>>
>>>>
>>>>>Luis and Jim:
>>>>>
>>>>>My obvious mistake: the initialParameters were not changed
>>>>>to 3D. After the change, it seems working fine: only one iteration is
>>>>>made.
>>>>>
>>>>>Here is the key output:
>>>>> Iteration = 1
>>>>> Metric value = -0.56463
>>>>> Stop Condition = 1
>>>>>
>>>>>Of course, the code does not recognize *.dcm as an output file name.
>>>>>That is the only problem, which may be coded as "Stop Condition = 1".
>>>>>
>>>>>So, for the output file, does ITK support dicom series as output file?
>>>>>Or what kind of output file format is does support?
>>>>>
>>>>>Thanks a lot for your previous helps.
>>>>>
>>>>>George
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Li, George (NIH/NCI)
>>>>>Sent: Friday, December 10, 2004 9:51 AM
>>>>>To: 'Luis Ibanez'
>>>>>Cc: 'insight-users at itk.org'; 'Miller, James V (Research)'
>>>>>Subject: RE: [Insight-users] RE: Error: jointPDFSum == 0!
>>>>>
>>>>>
>>>>>Luis:
>>>>>
>>>>>I don't get any output from the observer. It throws
>>>>>the exception pretty early in the execution, not even done the first
>>>>>iteration. I have followed the VC6 debugger into the code, it is
>>>>>stopped at the first time of getting metric value. Therefore, it might
>>>>>be suspicious that I have not done the initialization correctly with
>>>>>ITK. For instance, It might miss a step of something. If you can do a
>>>>>quick check on the code for me, it will be greatly appreciated.
>>>>>
>>>>>Here I attached two files: one is the complete code I used based on
>>>>>the modification of the two examples, and the other is the output of
>>>>>the messages by execute the code. hopefully, it will helpful to nail
>>>>>down the problem.
>>>>>
>>>>>I really appreciate all of the helping efforts you guys provide.
>>>>>
>>>>>Thanks,
>>>>>
>>>>>George
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
>>>>>Sent: Friday, December 10, 2004 12:24 AM
>>>>>To: Li, George (NIH/NCI)
>>>>>Cc: 'Miller, James V (Research)'; 'insight-users at itk.org'
>>>>>Subject: Re: [Insight-users] RE: Error: jointPDFSum == 0!
>>>>>
>>>>>
>>>>>
>>>>>Hi George,
>>>>>
>>>>>The Example ImageRegistration4.cxx has already a Command/Observer
>>>>>connected to the optimizer.
>>>>>
>>>>>When you run the example... do you get any output
>>>>
>>>>>from this observer ?
>>>>
>>>>
>>>>>It should be something like an iteration number,
>>>>>the metric value and the list of transform parameters (potentially
>>>>>many of those lines).
>>>>>
>>>>>Please post the the list *all* the messages that you
>>>>>get before you see the exception being thrown.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Luis
>>>>>
>>>>>
>>>>>--------------------------------
>>>>>Li, George (NIH/NCI) wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Jim:
>>>>>>
>>>>>>I used the same image series for both fixed and moving images, so
>>>>>>that
>>>>>>it is guaranteed to have overlap between the two. Of course,
>>>>>>presumably the origin of the two is the same, as it was indicated in
>>>>>>both print-out of the images (I did not provide both in my previous
>>>>>>mail, because they are identical).
>>>>>>
>>>>>>Based on your explanation on the exception message, similar to what I
>>>>>>guessed from these words, there must be something else that has not
>>>>>>been set correctly, rather than the image series themselves.
>>>>>>
>>>>>>Based on your experience, do you think my simple approach to register
>>>>>>3D images is valid? I did simple substitution of imageFileReader in
>>>>>>the imageRegistration4.cxx by the dicomSeriesReader from the other
>>>>>>example. I assumed that the registration behind the scene is
>>>>>>implemented independent of the dimension of the image, as it should.
>>>>>>
>>>>>>Anyway, I am new to ITK and your input is very valuable.
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>George
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Miller, James V (Research) [mailto:millerjv at crd.ge.com]
>>>>>>Sent: Thursday, December 09, 2004 1:56 PM
>>>>>>To: Li, George (NIH/NCI); 'insight-users at itk.org'
>>>>>>Subject: RE: [Insight-users] RE: Error: jointPDFSum == 0!
>>>>>>
>>>>>>
>>>>>>George,
>>>>>>
>>>>>>What is the origin of the other image?
>>>>>>
>>>>>>It looks like the origin of one image is [0, 0, -1264.5].
>>>>>>
>>>>>>Your transform is probably initially the identity, resulting in an
>>>>>>assumption that the two image set overlap in physical space (meaning
>>>>>>if you laid out the two images pinned down at their respective
>>>>>>origins, and the sizes of the image took into account the spacing of
>>>>>>the pixels, then the two images would overlap).
>>>>>>
>>>>>>Whenever you get the message
>>>>>>
>>>>>>Too many samples map outside moving image buffer: 0 / 10000
>>>>>>
>>>>>>It means the fixed and moving image are not overlapping (after the
>>>>>>application of the current transform). A set of points is selected in
>>>>>>on of the images and mapped through the transform to identify
>>>>>>locations in the other image. If the mapping puts all the samples
>>>>>>outside the other image, then an exception occurs.
>>>>>>
>>>>>>If you "know" the images are supposed to span the same region of
>>>>>>anatomy, then the two image series may simply have had different
>>>>>>landmarks prescribed during acquisition. In this case, you can
>>>>>>either set the initial transformation to be a translation of
>>>>>>
>>>>>> movingImageReader->GetOutput()->GetOrigin() -
>>>>>>fixedImageReader->GetOutput()->GetOrigin()
>>>>>>
>>>>>>or you can use the ChangeInformationImageFilter to override the
>>>>>>origin
>>>>>>of one of the images.
>>>>>>
>>>>>>Jim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Li, George (NIH/NCI) [mailto:ligeorge at mail.nih.gov]
>>>>>>Sent: Wednesday, December 08, 2004 10:08 AM
>>>>>>To: 'Miller, James V (Research)'; 'insight-users at itk.org'
>>>>>>Subject: RE: [Insight-users] RE: Error: jointPDFSum == 0!
>>>>>>
>>>>>>
>>>>>>Jim:
>>>>>>
>>>>>>Thanks for the tip to print out the image. Here is the print out
>>>>>>content about the image and the exception. Maybe it will give a clue
>>>>>>to what has gone wrong. This time, the exception seems thrown out a
>>>>>>bit earlier in the
>>>>>>GetValue() method. It complains "Too many samples map outside moving
>>>>>>image buffer" at the end.
>>>>>>
>>>>>>
>>>>>>Argument[1]: ..\ITK_Data\PQ_HDR_VR-vr
>>>>>>Argument[2]: ..\ITK_Data\PQ_HDR_VR-vr
>>>>>>
>>>>>>Now reading series:
>>>>>>
>>>>>>2.16.840.1.113662.2.2534022882858481901029150326.1
>>>>>>Image (0166FE68)
>>>>>>RTTI typeinfo: class itk::Image<unsigned short,3>
>>>>>>Reference Count: 1
>>>>>>Modified Time: 2805
>>>>>>Debug: Off
>>>>>>Observers:
>>>>>> none
>>>>>>Source: (0166DA80)
>>>>>>Source output index: 0
>>>>>>Release Data: Off
>>>>>>Data Released: False
>>>>>>Global Release Data: Off
>>>>>>PipelineMTime: 1447
>>>>>>UpdateMTime: 2806
>>>>>>LargestPossibleRegion:
>>>>>> Dimension: 3
>>>>>> Index: [0, 0, 0]
>>>>>> Size: [512, 512, 43]
>>>>>>BufferedRegion:
>>>>>> Dimension: 3
>>>>>> Index: [0, 0, 0]
>>>>>> Size: [512, 512, 43]
>>>>>>RequestedRegion:
>>>>>> Dimension: 3
>>>>>> Index: [0, 0, 0]
>>>>>> Size: [512, 512, 43]
>>>>>>Spacing: [0.742188, 0.742188, 10]
>>>>>>Origin: [0, 0, -1264.5]
>>>>>>PixelContainer:
>>>>>> ImportImageContainer (0166FF80)
>>>>>> RTTI typeinfo: class itk::ImportImageContainer<unsigned long,
>>>>>>unsigned short>
>>>>>> Reference Count: 1
>>>>>> Modified Time: 1515
>>>>>> Debug: Off
>>>>>> Observers:
>>>>>> none
>>>>>> Pointer: 0166FFB0
>>>>>> Container manages memory: true
>>>>>> Size: 11272192
>>>>>> Capacity: 11272192
>>>>>>
>>>>>>ExceptionObject caught !
>>>>>>
>>>>>>itk::ExceptionObject (0104FBE4)
>>>>>>Location: "Unknown"
>>>>>>File: C:\Programming\ITK_1.8.0\InsightToolkit-1.8.0\Code\Algorithms\
>>>>>>itkMattesMutualInformationImageToImageMetric.txx
>>>>>>Line: 623
>>>>>>Description: itk::ERROR:
>>>>>>MattesMutualInformationImageToImageMetric(01667B50):
>>>>>>Too many samples map outside moving image buffer: 0 / 10000
>>>>>>
>>>>>>
>>>>>>I checked the origin with another image series, it has all zero value
>>>>>>but with the same exception, so the negative z0 should not be
>>>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>cause.
>>>>>>
>>>>>>Any idea about "Too many samples map outside moving image Buffer"?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>George
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Miller, James V (Research) [mailto:millerjv at crd.ge.com]
>>>>>>Sent: Tuesday, December 07, 2004 2:49 PM
>>>>>>To: Li, George (NIH/NCI); 'insight-users at itk.org'
>>>>>>Subject: RE: [Insight-users] RE: Error: jointPDFSum == 0!
>>>>>>
>>>>>>
>>>>>>George,
>>>>>>
>>>>>>Are the images being read in correctly? After you do a
>>>>>>fixedImageReader->Update(), can you print out the image
>>>>>>
>>>>>> fixedImageReader->GetOutput()->Print(std::cout);
>>>>>>
>>>>>>(and the same for the moving image) to make sure the images have the
>>>>>>proper resolution?
>>>>>>
>>>>>>Jim
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Li, George (NIH/NCI) [mailto:ligeorge at mail.nih.gov]
>>>>>>Sent: Tuesday, December 07, 2004 1:48 PM
>>>>>>To: 'insight-users at itk.org'
>>>>>>Subject: [Insight-users] RE: Error: jointPDFSum == 0!
>>>>>>
>>>>>>
>>>>>>BTW, even if I used the identical dicom image series
>>>>>>for both fixedImage and movingImage, this problem is
>>>>>>still there. In this case, jointPDFSum must equal to
>>>>>>1.0. So, it shouldn't be image data related problem,
>>>>>>unless the data is not read properly or completely.
>>>>>>
>>>>>>As a matter of fact, I think jointPDFSum is assigned
>>>>>>by a value that is not initialized, because in VC6++
>>>>>>debug tool, jointPDFSum value is 1.#QNAN00000000000.
>>>>>>
>>>>>>Anyone can help me with this?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>George
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>Hi, Luis and insight users:
>>>>>>
>>>>>>I did a test to combine two examples together and
>>>>>>see how image registration can be applied to 3D
>>>>>>image series. Enclosed please find my code for the registration of 3D
>>>>>>image series.
>>>>>>
>>>>>>Basically, I used the ImageRegistration4.cxx as the
>>>>>>major code but replaced the image reading part with corresponding
>>>>>>code
>>>>>>in DicomSeriesReadImageWrite.cxx.
>>>>>>
>>>>>>Unfortunately, I got an exception that is related a
>>>>>>zero sum for the jointPDFSum, which supposed to be 1,
>>>>>>inside itkMattesMutualInformationImageToImageMetric::
>>>>>>GetValue().
>>>>>>
>>>>>>What could be done wrong here? Is there extra things
>>>>>>need to be done for the image series, comparing with
>>>>>>single image file?
>>>>>>
>>>>>>Thanks a lot.
>>>>>>
>>>>>>George
>>>>>>
>>>>>>_______________________________________________
>>>>>>Insight-users mailing list
>>>>>>Insight-users at itk.org
>>>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>>>>_______________________________________________
>>>>>>Insight-users mailing list
>>>>>>Insight-users at itk.org
>>>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>>>>_______________________________________________
>>>>>>Insight-users mailing list
>>>>>>Insight-users at itk.org
>>>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>Insight-users mailing list
>>>>>Insight-users at itk.org
>>>>>http://www.itk.org/mailman/listinfo/insight-users
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>>The directory:
>>>
>>>..\ITK_Data\$ACQSIM_vr
>>>
>>>Contains the following DICOM Series:
>>>
>>>2.16.840.1.113662.2.12.0.3012.979218961.1094
>>>
>>>
>>>Now reading series:
>>>
>>>2.16.840.1.113662.2.12.0.3012.979218961.1094
>>>Image (0166DE70)
>>> RTTI typeinfo: class itk::Image<unsigned short,3>
>>> Reference Count: 1
>>> Modified Time: 4203
>>> Debug: Off
>>> Observers:
>>> none
>>> Source: (0166BAA0)
>>> Source output index: 0
>>> Release Data: Off
>>> Data Released: False
>>> Global Release Data: Off
>>> PipelineMTime: 85
>>> UpdateMTime: 4204
>>> LargestPossibleRegion:
>>> Dimension: 3
>>> Index: [0, 0, 0]
>>> Size: [512, 512, 135]
>>> BufferedRegion:
>>> Dimension: 3
>>> Index: [0, 0, 0]
>>> Size: [512, 512, 135]
>>> RequestedRegion:
>>> Dimension: 3
>>> Index: [0, 0, 0]
>>> Size: [512, 512, 135]
>>> Spacing: [0.78125, 0.78125, 3]
>>> Origin: [-200, -540.5, 5]
>>> PixelContainer:
>>> ImportImageContainer (0166DF88)
>>> RTTI typeinfo: class itk::ImportImageContainer<unsigned long,unsigned sh
>>>ort>
>>> Reference Count: 1
>>> Modified Time: 153
>>> Debug: Off
>>> Observers:
>>> none
>>> Pointer: 0166DFB8
>>> Container manages memory: true
>>> Size: 35389440
>>> Capacity: 35389440
>>>
>>>The directory:
>>>
>>>..\ITK_Data\$ACQSIM_vr
>>>
>>>Contains the following DICOM Series:
>>>
>>>2.16.840.1.113662.2.12.0.3012.979218961.1094
>>>
>>>
>>>Now reading series:
>>>
>>>2.16.840.1.113662.2.12.0.3012.979218961.1094
>>>Image (0166FE68)
>>> RTTI typeinfo: class itk::Image<unsigned short,3>
>>> Reference Count: 1
>>> Modified Time: 8327
>>> Debug: Off
>>> Observers:
>>> none
>>> Source: (0166DA80)
>>> Source output index: 0
>>> Release Data: Off
>>> Data Released: False
>>> Global Release Data: Off
>>> PipelineMTime: 4207
>>> UpdateMTime: 8326
>>> LargestPossibleRegion:
>>> Dimension: 3
>>> Index: [0, 0, 0]
>>> Size: [512, 512, 135]
>>> BufferedRegion:
>>> Dimension: 3
>>> Index: [0, 0, 0]
>>> Size: [512, 512, 135]
>>> RequestedRegion:
>>> Dimension: 3
>>> Index: [0, 0, 0]
>>> Size: [512, 512, 135]
>>> Spacing: [0.78125, 0.78125, 3]
>>> Origin: [-195, -535.5, 10]
>>> PixelContainer:
>>> ImportImageContainer (0166FF80)
>>> RTTI typeinfo: class itk::ImportImageContainer<unsigned long,unsigned sh
>>>ort>
>>> Reference Count: 1
>>> Modified Time: 4275
>>> Debug: Off
>>> Observers:
>>> none
>>> Pointer: 0166FFB0
>>> Container manages memory: true
>>> Size: 35389440
>>> Capacity: 35389440
>>>Argument[1]: ..\ITK_Data\$ACQSIM_vr
>>>Argument[2]: ..\ITK_Data\$ACQSIM_vr
>>>Argument[3]: .\RegistrationResult.dcm
>>>-0.310524 0 [3.07622, 2.51101, 0.481334]
>>>-0.364004 1 [6.78316, 4.01137, 0.56825]
>>>-0.390155 2 [5.29954, 2.89136, 1.30611]
>>>-0.387506 3 [4.56911, 4.30798, 2.51428]
>>>-0.445155 4 [5.54494, 4.51697, 2.45042]
>>>-0.446694 5 [5.22221, 4.22741, 2.69941]
>>>-0.439147 6 [4.86418, 4.57291, 2.64994]
>>>-0.463999 7 [5.08274, 4.69045, 2.61974]
>>>-0.475687 8 [4.96833, 4.65277, 2.65313]
>>>-0.480961 9 [5.01503, 4.67878, 2.68551]
>>>-0.481786 10 [4.99419, 4.65822, 2.69644]
>>>-0.48197 11 [4.99791, 4.66835, 2.72576]
>>>-0.481875 12 [4.99008, 4.64304, 2.74233]
>>>-0.481487 13 [4.99555, 4.65413, 2.75189]
>>>-0.481755 14 [4.99456, 4.65025, 2.76699]
>>>-0.481541 15 [4.99616, 4.64916, 2.7825]
>>>-0.481288 16 [4.99346, 4.64456, 2.79718]
>>>-0.480902 17 [5.00045, 4.64849, 2.81059]
>>>-0.480914 18 [4.99423, 4.64435, 2.81287]
>>>-0.480537 19 [4.99608, 4.64371, 2.81625]
>>>-0.480424 20 [4.99439, 4.64431, 2.81972]
>>>-0.480357 21 [4.99636, 4.64213, 2.82229]
>>>-0.480201 22 [4.99547, 4.64363, 2.82316]
>>>-0.480238 23 [4.99483, 4.643, 2.82489]
>>>-0.480166 24 [4.99608, 4.64375, 2.82619]
>>>Result =
>>> Translation X = 4.99608
>>> Translation Y = 4.64375
>>> Translation Z = 2.82619
>>> Iterations = 26
>>> Metric value = -0.480155
>>> Stop Condition = 2
>>>Argument[1]: ..\ITK_Data\$ACQSIM_vr
>>>Argument[2]: ..\ITK_Data\$ACQSIM_vr
>>>Argument[3]: .\RegistrationResult.dcm
>>>Press any key to continue
>>
>>
>>
>>
>>_______________________________________________
>>Insight-users mailing list
>>Insight-users at itk.org
>>http://www.itk.org/mailman/listinfo/insight-users
>
>
>
>
More information about the Insight-users
mailing list