These are chat archives for thunder-project/thunder

1st
Apr 2015
tomsains
@tomsains
Apr 01 2015 00:20
@freeman-lab thank you! will make sure I keep up to date in future!
tomsains
@tomsains
Apr 01 2015 13:45

@freeman-lab Image registration currently adds pixels with a value of 0 at the edge of images in order to keep dims the same as the dims of the reference image when preforming a transformation. The result is there will be a band of voxels at the edge of an image which suddenly go from a normal time series to 0 - this may create some problems with machine learning due to their high variance which is highly correlated.

I have currently been manually cropping out this dead space at the edge of my image but it might make sense to incorporate a cropping function into the image Registration model i.e once images are aligned the max transformation in x and y for the time series could be subtracted from the original dims to give post registration dims?

Jeremy Freeman
@freeman-lab
Apr 01 2015 16:18
@tomsains hm, i'm a little confused by this, the default behavior when applying registration should be to pad the extra area with the nearest pixel value, as it's done with the shift method here using the nearest option https://github.com/thunder-project/thunder/blob/master/python/thunder/imgprocessing/transformation.py#L37-46
if nearest -> constant then it would fill with zeros
but i'm wondering if this isn't working as expected for some reason
@poolio @d-v-b @nvladimus any ideas here? you've done a lot with the registration, has anyone encountered the behavior @tomsains describes?
Davis Bennett
@d-v-b
Apr 01 2015 16:19
I remember us talking about how to set the boundary conditions and we decided against 0-padding for this reason
Jeremy Freeman
@freeman-lab
Apr 01 2015 16:19
yeah exactly
that's what i thought as well
Jeremy Freeman
@freeman-lab
Apr 01 2015 19:30
@tomsains i will look into this more and see if i can confirm the behavior you describe, could be that nearest is behaving in an unusual way on your data