Removing ImageMath dependency about antsr HOT 15 CLOSED

sounds good. i already fixed the aslCensoring dependency, just waiting on
test suite to run before committing.

for the labelStats xyz coords, should i just use the raw output from
labelgeometryimagefilter, or is there some other space that the coordinates
should be drawn from?

2015-06-09 11:47 GMT-04:00 stnava [email protected]:

@jeffduda https://github.com/jeffduda @bkandel
https://github.com/bkandel

ANTsR will be "broken" for a while ... Being tired of this ongoing issue,
I did the aggressive thing and removed imageMath and src/ImageMath.cpp and
also updated the antstag s.t. ImageMath is not compiled in core. here are
the current issues:

• checking R code for possible problems ... NOTE
  aslCensoring : aslOutlierRejection: no visible global function
  definition for ‘imageMath’
  basicInPaint: no visible global function definition for ‘imageMath’
  compcor: no visible global function definition for ‘imageMath’
  getCentroids: no visible global function definition for ‘imageMath’
  getTemplateCoordinates: no visible global function definition for
  ‘imageMath’
  projectImageAlongAxis: no visible global function definition for
  ‘imageMath’
  sliceTimingCorrection: no visible global function definition for
  ‘imageMath’
• checking Rd files ... OK

relating to:

ANTsR/R/aslCensoring.R: imageMath(4, diffs, "TimeSeriesSimpleSubtraction", asl)
ANTsR/R/basicInPaint.R: imageMath(img@dimension, temp, "MD", temp, 1)
ANTsR/R/basicInPaint.R: # imageMath(img@dimension,paintMaskUse,'GD',paintMask,1)
ANTsR/R/basicInPaint.R: imageMath(inpainted@dimension, inpainted, "FastMarchingExtension", speedimage,
ANTsR/R/compcor.R: imageMath(4, myoutfn, "CompCorrAuto", fmri, mask, ncompcor)
ANTsR/R/getCentroids.R: imageMath(imagedim, pointfile, "LabelStats", img, img, clustparam)
ANTsR/R/getTemplateCoordinates.R: imageMath(milab@dimension, pointfile, "LabelStats",
ANTsR/R/pairwiseImageDistanceMatrix.R: # broken !! metric <- capture.output(imageMath(dim, 'j', metrictype, i1,
ANTsR/R/projectImageAlongAxis.R: imageMath(imageND@dimension, downimg, "Project", imageND, axis, projtype)
ANTsR/R/sliceTimingCorrection.R: imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime, interpolation,
ANTsR/R/sliceTimingCorrection.R: imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime, interpolation,
ANTsR/R/sliceTimingCorrection.R: imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime)

here is a commit that deals with some of these:

3713fd8
3713fd8

however it would be good to get the rest as well ...

@jeffduda https://github.com/jeffduda a few pieces of functionality in
iMath

Project operator from ImageMath

FastMarchingExtension

@bkandel https://github.com/bkandel add x, y, z, t to labelStats ...
the output is always 4D centroids ... e.g. in 2D it will contain x_i, y_i,
0, 0 ( or maybe NA, NA ) ....

the other issues should be self explanatory.

—
Reply to this email directly or view it on GitHub
#53.

from antsr.

i forgot about labelGeometryMeasures, in part because it was broken. so i will fix the calls to labelStats by using this instead. so never mind about labelStats ....

from antsr.

done.

from antsr.

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R:    imageMath(4, diffs, "TimeSeriesSimpleSubtraction", asl)
R/sliceTimingCorrection.R:    imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R:    imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R:    imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime)

from antsr.

We should probably just get rid of sliceTimingCorrection.R for now. It
makes a number of assumption which aren't true for data that is currently
being collected.

On Tue, Jun 9, 2015 at 1:43 PM stnava [email protected] wrote:

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R: imageMath(4, diffs, "TimeSeriesSimpleSubtraction", asl)
R/sliceTimingCorrection.R: imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected, "SliceTimingCorrection", fmri, sliceTime)

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

i am ok with that and will implement now.

any thoughts on the other 2: (1) projection (2) fast marching extension ?

brian

On Tue, Jun 9, 2015 at 2:46 PM, Jeffrey Duda [email protected]
wrote:

We should probably just get rid of sliceTimingCorrection.R for now. It
makes a number of assumption which aren't true for data that is currently
being collected.

On Tue, Jun 9, 2015 at 1:43 PM stnava [email protected] wrote:

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R: imageMath(4, diffs, "TimeSeriesSimpleSubtraction", asl)
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime)

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

I can work on those today.

On Tue, Jun 9, 2015 at 3:10 PM stnava [email protected] wrote:

i am ok with that and will implement now.

any thoughts on the other 2: (1) projection (2) fast marching extension ?

brian

On Tue, Jun 9, 2015 at 2:46 PM, Jeffrey Duda [email protected]
wrote:

We should probably just get rid of sliceTimingCorrection.R for now. It
makes a number of assumption which aren't true for data that is currently
being collected.

On Tue, Jun 9, 2015 at 1:43 PM stnava [email protected] wrote:

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R: imageMath(4, diffs, "TimeSeriesSimpleSubtraction",
asl)
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime)

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

rather than make "project" part of iMath, i wrote apply.antsImage. This has
the advantage of being much more R-like and allowing an arbitrary function
to be used for the projection. It's just a wrapper for apply that handles
the header info.

On Tue, Jun 9, 2015 at 3:13 PM Jeffrey Duda [email protected] wrote:

I can work on those today.

On Tue, Jun 9, 2015 at 3:10 PM stnava [email protected] wrote:

i am ok with that and will implement now.

any thoughts on the other 2: (1) projection (2) fast marching extension ?

brian

On Tue, Jun 9, 2015 at 2:46 PM, Jeffrey Duda [email protected]
wrote:

We should probably just get rid of sliceTimingCorrection.R for now. It
makes a number of assumption which aren't true for data that is
currently
being collected.

On Tue, Jun 9, 2015 at 1:43 PM stnava [email protected] wrote:

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R: imageMath(4, diffs, "TimeSeriesSimpleSubtraction",
asl)
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime)

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

that makes sense, of course. probably very useful if we can figure out
what to do with it.

one issue is how to take care of the header info - guess you can wrap that
into apply.

brian

On Tue, Jun 9, 2015 at 5:15 PM, Jeffrey Duda [email protected]
wrote:

rather than make "project" part of iMath, i wrote apply.antsImage. This has
the advantage of being much more R-like and allowing an arbitrary function
to be used for the projection. It's just a wrapper for apply that handles
the header info.

On Tue, Jun 9, 2015 at 3:13 PM Jeffrey Duda [email protected] wrote:

I can work on those today.

On Tue, Jun 9, 2015 at 3:10 PM stnava [email protected] wrote:

i am ok with that and will implement now.

any thoughts on the other 2: (1) projection (2) fast marching extension
?

brian

On Tue, Jun 9, 2015 at 2:46 PM, Jeffrey Duda [email protected]
wrote:

We should probably just get rid of sliceTimingCorrection.R for now. It
makes a number of assumption which aren't true for data that is
currently
being collected.

On Tue, Jun 9, 2015 at 1:43 PM stnava [email protected]
wrote:

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R: imageMath(4, diffs, "TimeSeriesSimpleSubtraction",
asl)
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime)

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

looks like FastMarchingExtension may be the only thing left ... that may
also be better off in a separate location than iMath ...

brian

On Tue, Jun 9, 2015 at 5:18 PM, brian avants [email protected] wrote:

that makes sense, of course. probably very useful if we can figure out
what to do with it.

one issue is how to take care of the header info - guess you can wrap that
into apply.

brian

On Tue, Jun 9, 2015 at 5:15 PM, Jeffrey Duda [email protected]
wrote:

rather than make "project" part of iMath, i wrote apply.antsImage. This
has
the advantage of being much more R-like and allowing an arbitrary function
to be used for the projection. It's just a wrapper for apply that handles
the header info.

On Tue, Jun 9, 2015 at 3:13 PM Jeffrey Duda [email protected] wrote:

I can work on those today.

On Tue, Jun 9, 2015 at 3:10 PM stnava [email protected] wrote:

i am ok with that and will implement now.

any thoughts on the other 2: (1) projection (2) fast marching
extension ?

brian

On Tue, Jun 9, 2015 at 2:46 PM, Jeffrey Duda <[email protected]

wrote:

We should probably just get rid of sliceTimingCorrection.R for now.
It
makes a number of assumption which aren't true for data that is
currently
being collected.

On Tue, Jun 9, 2015 at 1:43 PM stnava [email protected]
wrote:

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R: imageMath(4, diffs,
"TimeSeriesSimpleSubtraction",
asl)
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime)

—
Reply to this email directly or view it on GitHub
<#53 (comment)
.

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

Was thinking the same. Will make it, it's own .cpp

On Tue, Jun 9, 2015 at 5:29 PM stnava [email protected] wrote:

looks like FastMarchingExtension may be the only thing left ... that may
also be better off in a separate location than iMath ...

brian

On Tue, Jun 9, 2015 at 5:18 PM, brian avants [email protected] wrote:

that makes sense, of course. probably very useful if we can figure out
what to do with it.

one issue is how to take care of the header info - guess you can wrap
that
into apply.

brian

On Tue, Jun 9, 2015 at 5:15 PM, Jeffrey Duda [email protected]
wrote:

rather than make "project" part of iMath, i wrote apply.antsImage. This
has
the advantage of being much more R-like and allowing an arbitrary
function
to be used for the projection. It's just a wrapper for apply that
handles
the header info.

On Tue, Jun 9, 2015 at 3:13 PM Jeffrey Duda [email protected]
wrote:

I can work on those today.

On Tue, Jun 9, 2015 at 3:10 PM stnava [email protected]
wrote:

i am ok with that and will implement now.

any thoughts on the other 2: (1) projection (2) fast marching
extension ?

brian

On Tue, Jun 9, 2015 at 2:46 PM, Jeffrey Duda <
[email protected]

wrote:

We should probably just get rid of sliceTimingCorrection.R for now.
It
makes a number of assumption which aren't true for data that is
currently
being collected.

On Tue, Jun 9, 2015 at 1:43 PM stnava [email protected]
wrote:

Remaining issues

MacBook-Pro:ANTsR stnava$ grep imageMath R/*
R/aslCensoring.R: imageMath(4, diffs,
"TimeSeriesSimpleSubtraction",
asl)
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime, interpolation,
R/sliceTimingCorrection.R: imageMath(4, corrected,
"SliceTimingCorrection", fmri, sliceTime)

—
Reply to this email directly or view it on GitHub
<
#53 (comment)
.

—
Reply to this email directly or view it on GitHub
<#53 (comment)
.

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

added some documentation to FastMarchingExtension and updated basicInPaint ...

not sure the documentation has the right usage of the mask ... you might want clean that up / make sure it works with an example .... if you get a chance to do so, let me know.

from antsr.

Looks like apply isn't a generic so we can't make it work like we do with
plot, but as it is, apply.antsImage should handle all the header info and
work the same as a call to apply with an array

On Wed, Jun 10, 2015 at 10:04 AM stnava [email protected] wrote:

added some documentation to FastMarchingExtension and updated basicInPaint
...

not sure the documentation has the right usage of the mask ... you might
want clean that up / make sure it works with an example .... if you get a
chance to do so, let me know.

—
Reply to this email directly or view it on GitHub
#53 (comment).

from antsr.

this is pretty close to done ... will close the issue once we get both codeship and travis passing ...

from antsr.

fixed an example bug. this appears to be ready to close now.

from antsr.