Dear CMTK Users,

My name is Zhilei Zhao. I'm a graduate student at Princeton University working on mosquito olfaction. 
I have segmentation of one brain region across many brains, i.e. 3D volumes of labels where each label is an integer corresponding to the same structure in different brains. I attached a screenshot of two brains to illustrate this better (each color is a label). 
Can I use CMTK to register these label volumes across brains? If so, are there any special parameters I should change, compared to registering regular fluorescence volumes?

Thanks a lot for your help!

Best,
Zhilei

Please see p18 of this cmtk guide

https://www.nitrc.org/docman/view.php/21...

Re data classes

I would imagine that this would be less accurate but more robust than using the raw image channel. It’s possible that you might use this to initialise a subsequent image based registration.

Torsten may well have additional suggestions. All the best, Greg.

See the help output of cmtk registration tool below, so I think you need 


additional command line options. Best, Greg.






Originally posted by Greg Jefferis:

Hi Prof. Jefferis,

Thank you so much for these helpful inputs! 
I will try it with my data and let you know how it goes.

Thanks,
Zhilei

The registration is working by specifying '--class-ref label --class-flt label' in the command line. However, to use munger I also need to specify the interpolation method of reformatx to be '--nn' (nearest neighbor). In the munger manual, it says '-2 [option] additional options for reformatx'. But when I added -2 '--nn' to the munger command, it output an error message:
Unknown option: 2
Unknown option: -
Unknown option: n
Unknown option: n

Anyone knows if I have some misunderstanding of this '-2' option? Full command is like this:
"$MUNGERDIR/munger" -b "$REGBINDIR" -i -a -w -r 0102 -T 22 -l af -X 16 -C 4 -G 32 -R 3 -A '--exploration 16 --accuracy 0.8 --class-ref label --class-flt label' -W '--accuracy 0.8 --energy-weight 5e-1 --class-ref label --class-flt label' -2 '--nn' -s refbrain/"${REFBRAIN}".nrrd images


Thanks! 
Zhilei

I think there must be a problem with your dash or your quote. Are you on Windows? Can you try without the -2 option and see if that actually runs.

I'm working on a Linux server.
Without the -2 '--nn', the command (below) ran correctly, just the labels in the reformatted volume had weird boundaries because of the wrong interpolation method. 
"$MUNGERDIR/munger" -b "$REGBINDIR" -i -a -w -r 0102 -T 22 -l af -X 16 -C 4 -G 32 -R 3 -A '--exploration 16 --accuracy 0.8 --class-ref label --class-flt label' -W '--accuracy 0.8 --energy-weight 5e-1 --class-ref label --class-flt label' -s refbrain/"${REFBRAIN}" images

Sorry it looks like this was only ever part implemented. You can edit the munger Perl script yourself to make the change that you can see here until it is incorporated

https://github.com/jefferis/cmtk/pull/4/...

This *should* fix the problem. Note that you can always reformat manually start the end.

Best,

Greg.

Awesome! By modifying the munger script as you suggested, it's working now with the -2 option. 

Thanks a lot!
Zhilei

That's great, glad to hear it's working. Best, Greg.

Seems that the avg_adm is unusually slow with the label data. To average across two volumes (~512*512*60), it takes more than 5 hours on the Linux with 22 threads, while the registration and reformatx only takes about a few minutes. Avg_adm on normal gray fluorescence data with the same size is also very fast on the same machine. Is this expected? My command line is like this:
avg_adm --verbose --label --nn --byte --auto-scale --no-ref-data --pad-out 0 --output-warp average/test -o NRRD:"refbrain/test_avg.nrrd" Registration/warp/labelDomesticTemplate-2_labelDomesticBrain1_01_warp_m0g32c4e1e-1x16r3.list/

Dear Zhilei,

I have never used avg_adm with label images. From the messages do you know if it the time is spent during the average deformation model calculation or the later step writing out the image volume? I wonder if it is having trouble converging because the label data is quite coarse.

Best,

Greg.

Seems that most of the time was spent on the averaging phase, instead of the writing phase, since the output file only appeared in the file system right before the command finished. By checking the averaged volume, I realized that the output volume doesn't make much sense, the labels were jumping to various random locations. So I guess it may be the converging problem you mentioned. 
Fortunately, I found an alternative analysis route that doesn't involve running avg_adm on label volumes, so it's not an urgent need anymore.

Thanks a lot!
Zhilei