users > CMTK does not generate proper reformatted files
Showing 1-13 of 13 posts
Display:
Results per page:
Jun 18, 2018  06:06 PM | Mahmood Hoseini - UCSF
CMTK does not generate proper reformatted files
Hello,

I have been running stacks registration using CMTK GUI. It runs fine but at the end the reformatted files are weird (attached is the first stack and the other stacks are completely white!). Has anyone encountered this problem before? Any suggestion?

Thanks,
-Mahmood
Attachment: first stack.png
Jun 19, 2018  02:06 AM | Greg Jefferis
RE: CMTK does not generate proper reformatted files
I think we need some more information here. Maybe show the nrrd header of the input and output files. You can use the ImageJ ... Image ... Show Info command for this. You could also include affine registration .list files.
Jun 19, 2018  10:06 AM | Mahmood Hoseini - UCSF
RE: CMTK does not generate proper reformatted files
Thanks Greg for your response. The zip file contains the image info screenshot (left: day1-refbrain, middle: day2, right: reformatted) as well as the affine registration .list folder.

-Mahmood
Jun 19, 2018  10:06 AM | Greg Jefferis
RE: CMTK does not generate proper reformatted files
Originally posted by Mahmood Hoseini:
Thanks Greg for your response. The zip file contains the image info screenshot (left: day1-refbrain, middle: day2, right: reformatted) as well as the affine registration .list folder.

-Mahmood

Sorry. That tar.gz file seems to be empty (123 bytes only). Can you try again?
Jun 19, 2018  12:06 PM | Mahmood Hoseini - UCSF
RE: CMTK does not generate proper reformatted files
Sorry. Attached again.
Jun 20, 2018  09:06 AM | Torsten Rohlfing - Google LLC
RE: CMTK does not generate proper reformatted files
Hi Mahmood -

Typically, when you see a stack "completely white" that means there was no overlap between the reference and the floating images after registration. As a result, all pixels in the reformatted image will be set to a "padding" value. To explain why that appears white - for integer data, the padding value defaults to "-1", but for unsigned data that is converted to the maximum allowed value, thus white.

Anyway, this suggests registration failure, and here are a few possible reasons why that might happen:

a) bad initialization (e.g., initial transformation is too far off from the correct alignment),

b) excessive optimization step size (i.e., the initial step size is large relative to the size of the images, allowing the algorithm to place one image outside the other altogether),

c) low content overlap between the images (i.e., the images represent different areas of the anatomy and there's only a small portion that's visible in both),

d) unsuitable image similarity metric (e.g., using correlation for label data).

Case a) could be addressed by providing a better initial transformation, for example using the "make_initial_affine_xform" tool. If all else fails, try providing a good initial transformation "by hand".

Case b) could be addressed by reducing the initial step size. Not sure how to do that through the GUI (?), though.

Case c) could be addressed by providing a good initial transformation and, in addition, reducing initial step size.

Case d) is actually quite unlikely, but obviously trying a different metric may help.

Best,
  Torsten
Jun 20, 2018  10:06 AM | Greg Jefferis
RE: CMTK does not generate proper reformatted files
I see that the range of your input images is *very* small 32741-33260. I wonder if there is a problem reading these images in. However after registration as Torsten explains padding values are added - these have value 0. So the range of your output image is 0-33260. This means that all the interesting values (in range 32741-33260) will look like white and there will be a big range 1-32740 that is not being used. If you set the display range of the image to 32741-33260 (image ... adjust ... brightness contrast) I think you may see your image appear/
Jun 20, 2018  10:06 AM | Torsten Rohlfing - Google LLC
RE: CMTK does not generate proper reformatted files
Just to add another reason why registration may fail -

e) too many degrees of freedom, or too many DOFs too early.

For example, if you have a lot of translation to account for, then also trying to compute rotation (perhaps also scale) at the same time may lead to rotation getting screwed up completely before translation had a chance to stabilize.

This could be addressed by running a series of registrations with increasing numbers of DOFs, e.g., start with 3 (translation only), then use the result as the input of 6 DOF registration, then move on to 7, then 9 DOFs, if applicable.

Note that both the registration and the registrationx tool also let you specify lists of DOFs per level, rather than just a single DOF. So instead of "--dofs 9" you could use "--dofs 3,6,7,9", and the tool would automatically run each registration level multiple times with increasing numbers of DOFs. It's not as flexible as running the tool repeatedly, but it's simpler and faster.
Jun 20, 2018  10:06 AM | Torsten Rohlfing - Google LLC
RE: CMTK does not generate proper reformatted files
To follow up on Greg's observation - depending on the registration metric, the offset in your value range may cause you problems also, in addition to the low range. Specifically the NCC and MSD metrics will very likely be completely thrown off by the fact that all your values are in the 30,000s. The histogram-based metrics may automatically account for that, but frankly, I don't remember, and I sure wouldn't bet on it.

Long story short - this would explain why registration fails, and the obvious solution would be to rescale your image intensities, say, by subtracting 32741 from all pixels (the imagemath and convertx tools can both do that for you).
Jun 21, 2018  09:06 AM | Mahmood Hoseini - UCSF
RE: CMTK does not generate proper reformatted files
Greg and Torsten--

Thank you so much. You are the best!

As you mentioned, the baseline intensity and the small range of intensities on each image was the issue and masking my images. I rescaled the intensities with imagemath and the images are fine now. Only the first and last frame are white/black which, I guess, is due to the stabilization issue. I was looking into defining dof by having "--dofs 3,6,7,9" but I'm getting an error. So where should I define the dofs and how?

-Mahmood
Jun 22, 2018  08:06 AM | Torsten Rohlfing - Google LLC
RE: CMTK does not generate proper reformatted files
Hi Mahmood - 

Glad to hear you're making progress :)

Regarding the DOFs option - are you running CMTK's registration tools directly or through a wrapper script (specifically, munger)?

If you are using a wrapper, then the DOFs options may either not be exposed at all, or they may be different.

If you are running either "registration" or "registrationx" directly, they should work though, unless I misremember something. You could always use the "--help" flag to get a specific tool to dump a list of supported options and see what the exact format should be.

Torsten
Jun 22, 2018  09:06 AM | Greg Jefferis
RE: CMTK does not generate proper reformatted files
Originally posted by Torsten Rohlfing:
If you are using a wrapper, then the DOFs options may either not be exposed at all, or they may be different.

If you are using the CMTK gui (and therefore the munger script) which is distributed with CMTK but written by me rather than Torsten, you need to supply extra parameters to the affine registration step using the -A option. There is an example of that on the CMTK gui help page:

http://flybrain.mrc-lmb.cam.ac.uk/dokuwi...
-A '--accuracy 0.4'

so you could change that to:
-A '--accuracy 0.4 --dofs 3,6,7,9'

You need to be careful that the single quotes stay as regular single quotes – I seem to remember someone having an issue on Windows in particular.

Best,

Greg.
Jun 25, 2018  08:06 AM | Mahmood Hoseini - UCSF
RE: CMTK does not generate proper reformatted files
Awesome. Now everything works perfectly!! I really appreciate your help.


-Mahmood