[Insight-users] Missing use of ReinitializeSeed in MutualInfo. metric?

[Luis Ibanez]

Hi Erik,

Thanks for pointing this out.

You are right,
we should invoke the ReinitializeSeed() method
as described in the Doxygen documentation,

http://www.itk.org/Insight/Doxygen/html/classitk_1_1MutualInformationImageToImageMetric.html
http://www.itk.org/Insight/Doxygen/html/classitk_1_1MattesMutualInformationImageToImageMetric.html


like


          metric->ReinitializeSeed();

Or

          metric->ReinitializeSeed( seedValue );


instead of having explicit calls to vnl_sample_reseed().

Note that most of the calls to vnl_sample_reseed() are
actually in the test drivers, and not in the examples
themselves. At that level, there are not metrics declared,
so the only access to reinitialization is through a direct
call to vnl_sample_reseed().

The reason for doing the reseeding there is that we need
to have repeateable behavior for the tests that are
including in the nightly and continuous regression testing
in the Dashboard.


However,
it will be clearer if we put the ReinitializeSeed()
call directly in the examples that need it.



Regards,



    Luis



--------------------
Erik Harg wrote:

> Hi,
> 
> I have a question regarding the randomness (or, rather, the lack of it) 
> of the random number generator in ImageRandomConstIteratorWithIndex, as 
> used in the MutualInformationImageToImageMetric.
> 
> In my experience, with the same number of sample points, and the same 
> fixed/moving images, the Iterator always chooses the same sample points, 
> and the resulting MI metric values are always identical. This is 
> occurring both under Mac OS X and Linux, using itk versions from 1.8 to 
> 2.0.
> 
> As far as I can tell, when the MutualInformationImageToImageMetric calls 
> the ++randIter, the increment operator of the 
> ImageConstIteratorWithIndex calls RandomJump(), which in turn uses 
> vnl_sample_uniform(). However, I have not been able to find any 
> preceding call to the reseed function of the iterator, nor directly to 
> the vnl_sample_reseed() functions. [1]
> 
> In the almost 6 months I have been watching this list, some threads 
> related to this issue have emerged, but (I believe) not covering exactly 
> what I am thinking about...
> 
> My question then, is this: Am I correct in noticing that the 
> MutualInformation Metric does not seed the random number generator, and 
> is there a good reason for it not to use its own ReinitializeSeed() 
> function (or the one in the Iterator)?
> 
> I notice that in some of the RegistrationExamples included with the itk 
> source, there are specific calls to vnl_sample_reseed(int seed), using 
> seed=8775070 or 76926294. However, wouldn't it be a more general 
> approach to let the MI metric, or even the Iterator, handle the seeding, 
> to ensure that the correct function is called?
> 
> There is probably a good answer to this, and I am looking forward to 
> hearing it! Thank you.
> 
> Regards,
> 
> Erik
> 
> 
> [1]
> Looking at the source code for the vnl (vnl_sample.cxx in the 
> Utilities/vxl/core/vnl directory of the itk source tree), it seems that 
> this function will either use the drand48() stdlib function if 
> available, or use a simple congruential random number generator. As far 
> as my understanding of (pseudo-)random number generators go, both of 
> these need a decent seed to provide anything close to random numbers. 
> The congruential generator that is built into the vnl has a static seed 
> of 12345, unless a call to vnl_sample_reseed() or vnl_sample_reseed(int 
> seed) precedes the vnl_sample_uniform() function call. However, when vnl 
> is using the drand48(), no default seeding (using srand48()) is done, 
> and I believe the last system provided seed is used(?). Thus, any call 
> to vnl_sample_uniform() should be preceded by a call to 
> vnl_sample_reseed() (which uses the vcl_time(0) as seed to srand48()), 
> or to vnl_sample_reseed(int seed) using some user defined seed. Only 
> this will ensure a basic pseudo-random behaviour of the uniform random 
> number generator, I believe.