[elastix] Elastix verbosity

M.Staring at lumc.nl M.Staring at lumc.nl
Fri Mar 19 11:54:11 CET 2010


Hi Mark, 

> 
> Hi Marius,
> 
> I can certainly take a look at the source and see what I can 
> do-- may take me a bit, since I'm inundated with projects at 
> the moment.

That's great!

> 
> What I'd like are three levels of verbosity redirected to cout:
> 0) errors, warnings, and progress (what it is now)
> 1) errors and warnings (so the 100 iterations of matching 
> don't show up)
> 2) errors only (so the warnings about what parameters are 
> missing don't show up)
> 3) pass/fail (the 0/1 output you described) So, when I run 
> the script (on windows atm, so I'll have to look into the 
> redirects there), I'd like to set --verbosity (or --v) to 
> some number between 0 and 3, with 0 as the default.
> 
> The problem as I see it is that I don't know where these 
> things are being piped at the moment-- is it all to cout and 
> cerr?  Or are you doing something where all outputs are sent 
> to a logging class, at which point I could determine which go 
> to cout and which do not?
> Because if you have the class already set up, I think it'd be 
> a trivial thing to change.  If not, it will take me a bit.  
> Also, I don't know how ITK does its error reporting, and it 
> appears to be itk problems I need reported, but I'm not sure.

We use some special classes for that. They can be found at:

	elastix\src\Common\xout

In elastix\src\Core\Kernel\elxElastixMain.cxx in the function xoutSetup() we set up the outputs. For example like:

	xout.AddOutput("cout", &std::cout);
	xout.AddTargetCell( "warning", &g_WarningXout );
  	xout.AddTargetCell( "error", &g_ErrorXout );

We already make a distinction in warnings, errors, etc. Currently, we sent everything to the elastix.log file. I don't think that should change, because it gives the user a place to find all details. We sent the iterations info to elastix.log and to iterationinfo.txt files and to std::cout. I think you can either alter the xout classes, or maybe better at the place(s) where xout is being setup. The new code should then take into account the verbosity options that are set by the user, so that based on these options for example xout["warning"] is connected to std::cout. I guess something like:

	if ( verbosity == 0 or 1 )
	{
	  xout.AddTargetCell( "warning", &g_WarningXout );
	}

Stefan can give you more information about the implementation details, since he created the xout stuff.

> 
> Also!  I've noticed a big change from 4.2 to 4.3 in the 
> ability to have 64-bitness.  With 4.2, affine registration of 
> a 90mb dataset to a 40 mb dataset could cause random crashes, 
> but doesn't happen in 4.3.
> I'm attributing that to having a larger memory space to work 
> with.  On windows 32 bit, you're very lucky if you can get 
> one or two large
> (>300mb) blocks of contiguous memory, and the chance of 
> allocation is definitely very random.  Is that kind of 
> allocation going on in elastix?  I'd like to think that my 
> problem was solved with the upgrade, but I want to have some 
> confidence in that beyond a few (>10) test runs.

We rely on the ITK for the internal storage of the image data. ITK currently only has one way of storage and that is in large contiguous blocks. So, that is indeed the kind of allocation that is going on in elastix. With 64 bit that is less of a problem. Note that elastix 4.2 is also suited for 64 bit; we just did not create a 64 bit Windows binary for that release.

When you say crash, do you then mean a hard segfault, or was an exception being thrown, catched and then elastix quited?

> 
> Thanks,
> Mark
> 
> On Thu, Mar 18, 2010 at 1:32 AM,  <M.Staring at lumc.nl> wrote:
> > Hi Mark,
> >
> > There exists an option
> >
> >        (PrintErrorMessages "false")
> >
> > which will print less/no error messages.
> >
> > This is not a commandline switch, but a parameter file entry.
> >
> > Note that in a bash script you can remove (redirect) all elastix 
> > output with
> >
> >        elastix -f .... >> /dev/null
> >
> > Unfortunately, you cannot control the elastix output with the 
> > granularity you want. I understand you like to have that feature to 
> > automatically detect what exactly went wrong in case of an error?
> >
> > Also note that elastix does exit with a return code: 0 if 
> everything 
> > went ok, 1 if something went wrong.
> >
> > Would you like to have different return codes for the 
> several errors 
> > you mention?
> >
> > Or would you like to have something easily grep-able in the 
> > elastix.log file, which enables automatic checking of the error?
> >
> > And: would you like to be the one that modifies the elastix 
> sources to 
> > implement this feature :-)
> >
> > Let me know if I understood your question correctly. Cheers,
> >
> > Marius
> >
> >> -----Original Message-----
> >> From: Mark Roden [mailto:mmroden at gmail.com]
> >> Sent: woensdag 17 maart 2010 22:07
> >> To: Staring, M. (LKEB)
> >> Cc: jonmorra at gmail.com; s.klein at eramusmc.nl; 
> >> daniel.valentino at gmail.com; elastix at bigr.nl
> >> Subject: Elastix verbosity
> >>
> >> Hi Marius,
> >>
> >> I'm having some problems with running elastix as part of a script.
> >> Unfortunately, the verbosity of elastix is very high, and there 
> >> doesn't appear to be a command-line switch to turn it 
> down.  Is there 
> >> one, and I'm just missing it?  I don't need to see the 100 
> iterations 
> >> to do registration, nor the missing parameters that aren't in the 
> >> text file.  I do, however, need to see the itk load errors 
> that are 
> >> happening, and figure out if that's a problem with inputs, 
> outputs, 
> >> and so forth.
> >>
> >> Thanks,
> >> Mark
> >>
> >
> 



More information about the Elastix mailing list