These are chat archives for thunder-project/thunder

5th
Feb 2015
Ben Poole
@poolio
Feb 05 2015 05:29
what's the philosophy on dependencies? For alignment and source extraction I have code that depends on statsmodels and scikit-image.
Jeremy Freeman
@freeman-lab
Feb 05 2015 05:30
good question! i think adding those two as dependencies is a minor inconvenience, but one we can accept
for local installs it's not a big deal because those are included with anaconda anyway (which is a common deployment), and if not, they are easy to get
it does mean adding them to our EC2 install, but we're doing that already with other libraries
Ben Poole
@poolio
Feb 05 2015 05:51
cool, thanks!
Ben Poole
@poolio
Feb 05 2015 06:48
is there a standard way to convert volumes into vectors, and back into volumes? I see subToInd and indToSub, but that looks like it's just for keys of Series objects. I typically use a vol2vec and vec2vol function that calls ravel and reshape, but then we need to keep track of the shape for each of the vectorized volumes.
Jason Wittenbach
@jwittenbach
Feb 05 2015 14:07
There's a chance I might be misunderstanding the question, but are the toSeries and toBlocks functions on Images and Series (respectively), perhaps what you're looking for?
Jeremy Freeman
@freeman-lab
Feb 05 2015 15:57
@poolio what data structure are you wanting to do this on, and what's the purpose? Maybe you're wanting to vectorize and unvectorize the individual records (images or volumes) or an Images object? In that case: it's not yet implemented, but we can discuss whether to add methods for it, or just make use of it within an analysis routine.
Ben Poole
@poolio
Feb 05 2015 18:37
Yes I want to vectorize/unvectorize an individual volume, contained as a single record of an Images object. This comes up in the Lucas-Kanade registration algorithm where we need to solve a linear system that has dimensions nvoxels by nparams. I need to view the volume both in its vectorized and unvectorized forms in the getTransform method that is applied via a map, so this reshaping method shouldn't be part of Images. Here's a snippet showing a hacky function that converts back and forth between vectors and volumes: https://gist.github.com/poolio/9a923135a70843c79691
wow, gitter embeds gists. so rad :)
industrial-sloth
@industrial-sloth
Feb 05 2015 19:39
Hey @poolio - I can definitively say no such method exists in Thunder. :) Your "hacky" implementation looks pretty much like how I'd do it though. I guess the question is then whether the appropriate place for such a beast would be on Images itself, versus possibly just contained within the registration algo that you're working on?
Also I think it would work to just call images.applyValues(np.ravel) to go from volume to vector, then images.applyValues(lambda vec: np.reshape(vec, orig_shape_tuple) for the reverse operation. Haven't actually tried this myself, YMMV. :)
Jeremy Freeman
@freeman-lab
Feb 05 2015 20:00
@poolio @industrial-sloth Cool, totally makes sense now. It sounds like this should just happen within the getTransform method. That function you posted looks perfectly reasonable, and a natural place for it (and its counterpart) would be inside imgprocessing/regmethods/utils.py. My guess is you won't want to call it via images.applyValues because it'll be specific to this reg method, and once you are inside the reg-method-specific getTransform you're working on a single record, not the original Images object.
Ben Poole
@poolio
Feb 05 2015 20:07
@industrial-sloth @freeman-lab I'll need to use this multiple times while working with a single volume, so I'll go ahead and put it in imgprocessing/regmethods/utils.py. Related, there are a bunch of volume processing methods that I can't decide where to put. Thinks like applying a gaussian filter, zeroing out a border, resizing a volume. Should that also go in utils.py? I think these could be more generally useful outside registration, but I don't think they should be methods of Images because they are simple functions that could be applied to individual volumes and not just RDDs.
Jeremy Freeman
@freeman-lab
Feb 05 2015 20:14
How about this: if these are useful helper methods that are relevant for registration, put them inside regmethods/utils.py for now as functions that work on images / volumes. We can always later add methods to Images that call these functions. But this way you can use them on single volumes within registration as well. Also note that there are already guassianFilter and medianFilter methods on Images that basically just call out to scipy functions, so this would be in a similar spirit.
Davis Bennett
@d-v-b
Feb 05 2015 20:59
@freeman-lab simple RDD question: when I call result = regressmodel.fit(imDat), how can I get the betas out of result
hmm nevermind, I think I know exactly what to do -- each element in result will have N items, where N is equal to the number of entries in result.index, so if result.index[0] = 'betas' then I can just just get the betas of the first entry via e.g. result.first()[1][0]
Jason Wittenbach
@jwittenbach
Feb 05 2015 21:19
And if you don't want to have to look-up/remember which spot in the index holds them, you can do result.select('betas')
Davis Bennett
@d-v-b
Feb 05 2015 21:20
cool!
Davis Bennett
@d-v-b
Feb 05 2015 22:15
@freeman-lab any suggestions on displaying the results of circular tuning on a large volume?
Jeremy Freeman
@freeman-lab
Feb 05 2015 23:58
beyond looking at it as an image?
should be bounded below by 0
so max projection makes sense