ImageMath strange results

[armaneshaghi]

Goal: test ImageMath for addtozero:

from man:

addtozero : add image-b to image-a only over points where image-a has zero values

Reproducible example:

require(ANTsR)
require(testthat)
         img1_array <- array(rep(2, 5*5), dim=c(5,5))
         img1_array[1,2] <- 0
         img1_array[2,3] <- 0
         img1_array[2,2] <- 0
         img1_array[3,3] <- 0
         img1_array[4,3] <- 0
         img1_array[4,3] <- 0
         img1_array[4,4] <- 0
         img1_array[4,3] <- 0
         img1_array[5,1] <- 0
         img2_array <- array(rep(2, 5*5), dim=c(5,5))

so:

> as.array(img1)
     [,1] [,2] [,3] [,4] [,5]
[1,]    2    0    2    2    2
[2,]    2    0    0    2    2
[3,]    2    2    0    2    2
[4,]    2    2    0    0    2
[5,]    0    2    2    2    2

and:

> as.array(img2)
     [,1] [,2] [,3] [,4] [,5]
[1,]    2    2    2    2    2
[2,]    2    2    2    2    2
[3,]    2    2    2    2    2
[4,]    2    2    2    2    2
[5,]    2    2    2    2    2

Moving on:

         img1 <- as.antsImage(img1_array)
         img2 <- as.antsImage(img2_array)
         output <- antsImageClone(img2)
         ImageMath(2, output, 'addtozero', img1, img2)

I would expect to get a homogenous array with 2s, but:

> as.array(output)
     [,1] [,2]          [,3]          [,4]          [,5]
[1,]    2    2  2.000000e+00 1.850677e-316 6.926506e-310
[2,]    2    2  2.000000e+00 3.127860e-316 4.940656e-324
[3,]    2    2  0.000000e+00 4.356597e-316 6.926506e-310
[4,]    2    2 4.431769e-321 1.037538e-321 6.926506e-310
[5,]    2    2 6.926606e-310 3.458460e-323 9.881313e-324

to check if casting could be a problem:

> img1@pixeltype
[1] "double"
> img2@pixeltype
[1] "double"
> output@pixeltype
[1] "double"

ImageMath.cxx:

 else if( strcmp(operation.c_str(), "addtozero") == 0 && pix1 == 0 )
      {
      result = pix1 + pix2;
      }
    else if( strcmp(operation.c_str(), "addtozero") == 0 && pix1 != 0 )
      {
      result = pix1;

Ideas?

Arman

[stnava]

casting looks like the problem there - all the ants programs are expecting
floats ... however, i am puzzled as to why your inputs are double ...

we are likely to "hide" imagemath in the future and go to iMath instead ...
so you might want to test iMath instead.

brian

On Wed, Feb 11, 2015 at 4:48 PM, Arman Eshaghi notifications@github.com
wrote:

Goal: test ImageMath for addtozero:

from man:

addtozero : add image-b to image-a only over points where image-a has zero values

Reproducible example:

require(ANTsR)
require(testthat)
img1_array <- array(rep(2, 5_5), dim=c(5,5))
img1_array[1,2] <- 0
img1_array[2,3] <- 0
img1_array[2,2] <- 0
img1_array[3,3] <- 0
img1_array[4,3] <- 0
img1_array[4,3] <- 0
img1_array[4,4] <- 0
img1_array[4,3] <- 0
img1_array[5,1] <- 0
img2_array <- array(rep(2, 5_5), dim=c(5,5))

so:

as.array(img1)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 0 2 2 2
[2,] 2 0 0 2 2
[3,] 2 2 0 2 2
[4,] 2 2 0 0 2
[5,] 0 2 2 2 2

and:

as.array(img2)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2 2 2
[2,] 2 2 2 2 2
[3,] 2 2 2 2 2
[4,] 2 2 2 2 2
[5,] 2 2 2 2 2

Moving on:

     img1 <- as.antsImage(img1_array)
     img2 <- as.antsImage(img2_array)
     output <- antsImageClone(img2)
     ImageMath(2, output, 'addtozero', img1, img2)

I would expect to get a homogenous array with 2s, but:

as.array(output)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2.000000e+00 1.850677e-316 6.926506e-310
[2,] 2 2 2.000000e+00 3.127860e-316 4.940656e-324
[3,] 2 2 0.000000e+00 4.356597e-316 6.926506e-310
[4,] 2 2 4.431769e-321 1.037538e-321 6.926506e-310
[5,] 2 2 6.926606e-310 3.458460e-323 9.881313e-324

to check if casting could be a problem:

img1@pixeltype
[1] "double"
img2@pixeltype
[1] "double"
output@pixeltype
[1] "double"

Ideas?

Arman

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

[jeffduda]

Was thinking about the iMath issue today. Would it make more sense to have
functions that call ImageMath be named after their operation and just call
ImageMath under the hood, rather than having an R swiss army function.
ie. instead of something like output <- iMath( input, "MD", 2) you would
have antsr.image.dilate( input, 2 ) so the user never knows or cares if
ImageMath is called.

On Wed, Feb 11, 2015 at 5:08 PM, stnava notifications@github.com wrote:

casting looks like the problem there - all the ants programs are expecting
floats ... however, i am puzzled as to how your inputs are not double ...

we are likely to "hide" imagemath in the future and go to iMath instead ...
so you might want to test iMath instead.

brian

On Wed, Feb 11, 2015 at 4:48 PM, Arman Eshaghi notifications@github.com
wrote:

Goal: test ImageMath for addtozero:

from man:

addtozero : add image-b to image-a only over points where image-a has
zero values

Reproducible example:

require(ANTsR)
require(testthat)
img1_array <- array(rep(2, 5_5), dim=c(5,5))
img1_array[1,2] <- 0
img1_array[2,3] <- 0
img1_array[2,2] <- 0
img1_array[3,3] <- 0
img1_array[4,3] <- 0
img1_array[4,3] <- 0
img1_array[4,4] <- 0
img1_array[4,3] <- 0
img1_array[5,1] <- 0
img2_array <- array(rep(2, 5_5), dim=c(5,5))

so:

as.array(img1)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 0 2 2 2
[2,] 2 0 0 2 2
[3,] 2 2 0 2 2
[4,] 2 2 0 0 2
[5,] 0 2 2 2 2

and:

as.array(img2)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2 2 2
[2,] 2 2 2 2 2
[3,] 2 2 2 2 2
[4,] 2 2 2 2 2
[5,] 2 2 2 2 2

Moving on:

img1 <- as.antsImage(img1_array)
img2 <- as.antsImage(img2_array)
output <- antsImageClone(img2)
ImageMath(2, output, 'addtozero', img1, img2)

I would expect to get a homogenous array with 2s, but:

as.array(output)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2.000000e+00 1.850677e-316 6.926506e-310
[2,] 2 2 2.000000e+00 3.127860e-316 4.940656e-324
[3,] 2 2 0.000000e+00 4.356597e-316 6.926506e-310
[4,] 2 2 4.431769e-321 1.037538e-321 6.926506e-310
[5,] 2 2 6.926606e-310 3.458460e-323 9.881313e-324

to check if casting could be a problem:

img1@pixeltype
[1] "double"
img2@pixeltype
[1] "double"
output@pixeltype
[1] "double"

Ideas?

Arman

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

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

[bkandel]

Not sure. This is a weird result (to me, at least):
library(ANTsR)
img1_array <- array(rep(2.0, 5_5), dim=c(5,5))
img1_array[1,2] <- 0.0
img1_array[2,3] <- 0.0
img1_array[2,2] <- 0.0
img1_array[3,3] <- 0.0
img1_array[4,3] <- 0.0
img1_array[4,3] <- 0.0
img1_array[4,4] <- 0.0
img1_array[4,3] <- 0.0
img1_array[5,1] <- 0.0
img2_array <- array(rep(2, 5_5), dim=c(5,5))
img1 <- as.antsImage(img1_array, 'float')
img2 <- as.antsImage(img2_array, 'float')
as.array(img1)
as.array(iMath(img1, 'Neg'))
as.array(img2)
as.array(iMath(img2, 'Neg'))

gives:

as.array(img1)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 0 2 2 2
[2,] 2 0 0 2 2
[3,] 2 2 0 2 2
[4,] 2 2 0 0 2
[5,] 0 2 2 2 2

as.array(iMath(img1, 'Neg'))
[,1] [,2] [,3] [,4] [,5]
[1,] 0 2 0 0 0
[2,] 0 2 2 0 0
[3,] 0 0 2 0 0
[4,] 0 0 2 2 0
[5,] 2 0 0 0 0

as.array(img2)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2 2 2
[2,] 2 2 2 2 2
[3,] 2 2 2 2 2
[4,] 2 2 2 2 2
[5,] 2 2 2 2 2

as.array(iMath(img2, 'Neg'))
[,1] [,2] [,3] [,4] [,5]
[1,] -1 -1 -1 -1 -1
[2,] -1 -1 -1 -1 -1
[3,] -1 -1 -1 -1 -1
[4,] -1 -1 -1 -1 -1
[5,] -1 -1 -1 -1 -1

On 11 February 2015 at 17:08, stnava notifications@github.com wrote:

casting looks like the problem there - all the ants programs are expecting
floats ... however, i am puzzled as to how your inputs are not double ...

we are likely to "hide" imagemath in the future and go to iMath instead ...
so you might want to test iMath instead.

brian

On Wed, Feb 11, 2015 at 4:48 PM, Arman Eshaghi notifications@github.com
wrote:

Goal: test ImageMath for addtozero:

from man:

addtozero : add image-b to image-a only over points where image-a has
zero values

Reproducible example:

require(ANTsR)
require(testthat)
img1_array <- array(rep(2, 5_5), dim=c(5,5))
img1_array[1,2] <- 0
img1_array[2,3] <- 0
img1_array[2,2] <- 0
img1_array[3,3] <- 0
img1_array[4,3] <- 0
img1_array[4,3] <- 0
img1_array[4,4] <- 0
img1_array[4,3] <- 0
img1_array[5,1] <- 0
img2_array <- array(rep(2, 5_5), dim=c(5,5))

so:

as.array(img1)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 0 2 2 2
[2,] 2 0 0 2 2
[3,] 2 2 0 2 2
[4,] 2 2 0 0 2
[5,] 0 2 2 2 2

and:

as.array(img2)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2 2 2
[2,] 2 2 2 2 2
[3,] 2 2 2 2 2
[4,] 2 2 2 2 2
[5,] 2 2 2 2 2

Moving on:

img1 <- as.antsImage(img1_array)
img2 <- as.antsImage(img2_array)
output <- antsImageClone(img2)
ImageMath(2, output, 'addtozero', img1, img2)

I would expect to get a homogenous array with 2s, but:

as.array(output)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2.000000e+00 1.850677e-316 6.926506e-310
[2,] 2 2 2.000000e+00 3.127860e-316 4.940656e-324
[3,] 2 2 0.000000e+00 4.356597e-316 6.926506e-310
[4,] 2 2 4.431769e-321 1.037538e-321 6.926506e-310
[5,] 2 2 6.926606e-310 3.458460e-323 9.881313e-324

to check if casting could be a problem:

img1@pixeltype
[1] "double"
img2@pixeltype
[1] "double"
output@pixeltype
[1] "double"

Ideas?

Arman

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

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

[armaneshaghi]

oh dear, there is a deeper problem, I think. We need to dig deep into ITK code.

[stnava]

would probably be

output <- imageBinaryDilation( input, 2 )

issue would be documenting all of the functions ... iMath sort of masks that need.

if this is the direction one wants to go, that's fine but then we can eliminate ImageMath altogether

( which means taking it out of the "core" ants program list )

i started work on this but didnt get very far ... anyway, steps would be:

• implement iMath.cpp which is the underlying swiss army knife or implement a cpp for each function
• add the corresponding .R function
• document / test that function

this would take some time but i'd be all for it ... one hidden danger is that this might lead to lots of R CMD check issues depending on what ends up in the .o file ... however, if we have our own flattened itk version anyway, these would be relatively easy to resolve

[stnava]

i would like to get rid of imagemath in antsr b/c it is the single largest file and b/c it takes forever to compile ... not sure how much of it we actually use - seems like about 10% ... so would rather implement that 10% elsewhere

[jeffduda]

Agreed, it's a bit of a behemoth. The iMath approach only partially masks
the documentation need, since what you end up with is a massive
documentation file for iMath. Probably best to write R/Rcpp code for the
things that we actually use in ANTsR.

On Wed, Feb 11, 2015 at 5:29 PM, stnava notifications@github.com wrote:

i would like to get rid of imagemath in antsr b/c it is the single largest
file and b/c it takes forever to compile ... not sure how much of it we
actually use - seems like about 10% ... so would rather implement that 10%
elsewhere

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

[stnava]

@bkandel - example 1 looks fine

example 2 is sort of undefined....

brian

On Wed, Feb 11, 2015 at 5:19 PM, bkandel notifications@github.com wrote:

Not sure. This is a weird result (to me, at least):
library(ANTsR)
img1_array <- array(rep(2.0, 5_5), dim=c(5,5))
img1_array[1,2] <- 0.0
img1_array[2,3] <- 0.0
img1_array[2,2] <- 0.0
img1_array[3,3] <- 0.0
img1_array[4,3] <- 0.0
img1_array[4,3] <- 0.0
img1_array[4,4] <- 0.0
img1_array[4,3] <- 0.0
img1_array[5,1] <- 0.0
img2_array <- array(rep(2, 5_5), dim=c(5,5))
img1 <- as.antsImage(img1_array, 'float')
img2 <- as.antsImage(img2_array, 'float')
as.array(img1)
as.array(iMath(img1, 'Neg'))
as.array(img2)
as.array(iMath(img2, 'Neg'))

gives:

as.array(img1)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 0 2 2 2
[2,] 2 0 0 2 2
[3,] 2 2 0 2 2
[4,] 2 2 0 0 2
[5,] 0 2 2 2 2

as.array(iMath(img1, 'Neg'))
[,1] [,2] [,3] [,4] [,5]
[1,] 0 2 0 0 0
[2,] 0 2 2 0 0
[3,] 0 0 2 0 0
[4,] 0 0 2 2 0
[5,] 2 0 0 0 0

as.array(img2)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2 2 2
[2,] 2 2 2 2 2
[3,] 2 2 2 2 2
[4,] 2 2 2 2 2
[5,] 2 2 2 2 2

as.array(iMath(img2, 'Neg'))
[,1] [,2] [,3] [,4] [,5]
[1,] -1 -1 -1 -1 -1
[2,] -1 -1 -1 -1 -1
[3,] -1 -1 -1 -1 -1
[4,] -1 -1 -1 -1 -1
[5,] -1 -1 -1 -1 -1

On 11 February 2015 at 17:08, stnava notifications@github.com wrote:

casting looks like the problem there - all the ants programs are
expecting
floats ... however, i am puzzled as to how your inputs are not double ...

we are likely to "hide" imagemath in the future and go to iMath instead
...
so you might want to test iMath instead.

brian

On Wed, Feb 11, 2015 at 4:48 PM, Arman Eshaghi <notifications@github.com

wrote:

Goal: test ImageMath for addtozero:

from man:

addtozero : add image-b to image-a only over points where image-a has
zero values

Reproducible example:

require(ANTsR)
require(testthat)
img1_array <- array(rep(2, 5_5), dim=c(5,5))
img1_array[1,2] <- 0
img1_array[2,3] <- 0
img1_array[2,2] <- 0
img1_array[3,3] <- 0
img1_array[4,3] <- 0
img1_array[4,3] <- 0
img1_array[4,4] <- 0
img1_array[4,3] <- 0
img1_array[5,1] <- 0
img2_array <- array(rep(2, 5_5), dim=c(5,5))

so:

as.array(img1)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 0 2 2 2
[2,] 2 0 0 2 2
[3,] 2 2 0 2 2
[4,] 2 2 0 0 2
[5,] 0 2 2 2 2

and:

as.array(img2)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2 2 2
[2,] 2 2 2 2 2
[3,] 2 2 2 2 2
[4,] 2 2 2 2 2
[5,] 2 2 2 2 2

Moving on:

img1 <- as.antsImage(img1_array)
img2 <- as.antsImage(img2_array)
output <- antsImageClone(img2)
ImageMath(2, output, 'addtozero', img1, img2)

I would expect to get a homogenous array with 2s, but:

as.array(output)
[,1] [,2] [,3] [,4] [,5]
[1,] 2 2 2.000000e+00 1.850677e-316 6.926506e-310
[2,] 2 2 2.000000e+00 3.127860e-316 4.940656e-324
[3,] 2 2 0.000000e+00 4.356597e-316 6.926506e-310
[4,] 2 2 4.431769e-321 1.037538e-321 6.926506e-310
[5,] 2 2 6.926606e-310 3.458460e-323 9.881313e-324

to check if casting could be a problem:

img1@pixeltype
[1] "double"
img2@pixeltype
[1] "double"
output@pixeltype
[1] "double"

Ideas?

Arman

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

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

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

[stnava]

@armaneshaghi

i think there is some problem in the class of operators in which addtozero lives ... not sure what

[bkandel]

Oh, I see. I misunderstood what an image negative is.

On 11 February 2015 at 17:40, stnava notifications@github.com wrote:

@armaneshaghi https://github.com/armaneshaghi

i think there is some problem in the class of operators in which addtozero
lives ... not sure what

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

[stnava]

@jeffduda seems this is what we use from ImageMath

CompCorrAuto, D, FastMarchingExtension, FillHoles, G, GD, GE,
GetLargestComponent, Grad, LabelStats, Laplacian, MakeImage,
MaurerDistance, ME, MD, Neg, Normalize, PadImage, PeronaMalik, Project,
SliceTimingCorrection, TruncateImageIntensity

attached is a starter iMath.cpp

brian

On Wed, Feb 11, 2015 at 5:43 PM, bkandel notifications@github.com wrote:

Oh, I see. I misunderstood what an image negative is.

On 11 February 2015 at 17:40, stnava notifications@github.com wrote:

@armaneshaghi https://github.com/armaneshaghi

i think there is some problem in the class of operators in which
addtozero
lives ... not sure what

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

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

[armaneshaghi]

Thanks @stnava we'll look into that

[jeffduda]

didn't get attachment. maybe start new branch for this?

On Wed, Feb 11, 2015 at 5:50 PM, stnava notifications@github.com wrote:

@jeffduda seems this is what we use from ImageMath

CompCorrAuto, D, FastMarchingExtension, FillHoles, G, GD, GE,
GetLargestComponent, Grad, LabelStats, Laplacian, MakeImage,
MaurerDistance, ME, MD, Neg, Normalize, PadImage, PeronaMalik, Project,
SliceTimingCorrection, TruncateImageIntensity

attached is a starter iMath.cpp

brian

On Wed, Feb 11, 2015 at 5:43 PM, bkandel notifications@github.com wrote:

Oh, I see. I misunderstood what an image negative is.

On 11 February 2015 at 17:40, stnava notifications@github.com wrote:

@armaneshaghi https://github.com/armaneshaghi

i think there is some problem in the class of operators in which
addtozero
lives ... not sure what

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

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

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

[stnava]

sure - will email it

brian

On Wed, Feb 11, 2015 at 5:59 PM, Jeffrey Duda notifications@github.com
wrote:

didn't get attachment. maybe start new branch for this?

On Wed, Feb 11, 2015 at 5:50 PM, stnava notifications@github.com wrote:

@jeffduda seems this is what we use from ImageMath

CompCorrAuto, D, FastMarchingExtension, FillHoles, G, GD, GE,
GetLargestComponent, Grad, LabelStats, Laplacian, MakeImage,
MaurerDistance, ME, MD, Neg, Normalize, PadImage, PeronaMalik, Project,
SliceTimingCorrection, TruncateImageIntensity

attached is a starter iMath.cpp

brian

On Wed, Feb 11, 2015 at 5:43 PM, bkandel notifications@github.com
wrote:

Oh, I see. I misunderstood what an image negative is.

On 11 February 2015 at 17:40, stnava notifications@github.com wrote:

@armaneshaghi https://github.com/armaneshaghi

i think there is some problem in the class of operators in which
addtozero
lives ... not sure what

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

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

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

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

[stnava]

i've been thinking more about this iMath utility ... here is a relevant example (i.e. there is precedent in R):

http://topepo.github.io/caret/modelList.html

for iMath to be really useful / interesting, it would have to be accompanied by a table like this that explains each operation. could be stored in a dataframe. otherwise, i can imagine an explosion of different functions that would be ever growing ... any thoughts appreciated.

[bkandel]

I agree. I think that a "Swiss army knife" function would actually be
nice. It is probably worth starting from scratch so that we don't have to
take with us the past 15 years of ANTs development in ImageMath, though,
and so that we focus on functions that will actually be used. For me, that
means focusing on the low-level image processing routines that can't easily
be done in R and skipping the numeric manipulation (log, neg, +, etc.) and
statistics functions.

A major difficulty is that we don't have a method for having namespaces or
modules in R, like we do in other languages. Ideally, we'd be able to call
ANTsR::imgproc::erode, but we obviously can't do that. I think that
iMath(img, 'erode', 2) is the closest we'll come. We could just put the
possible inputs in the "Details" section of the help (sort of like the ants
ImageMath current help, but ideally more informative).

On 12 February 2015 at 12:14, stnava notifications@github.com wrote:

i've been thinking more about this iMath utility ... here is a relevant
example (i.e. there is precedent in R):

http://topepo.github.io/caret/modelList.html

for iMath to be really useful / interesting, it would have to be
accompanied by a table like this that explains each operation. could be
stored in a dataframe. otherwise, i can imagine an explosion of different
functions that would be ever growing ... any thoughts appreciated.

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

[jeffduda]

I think the documentation is the biggest issue. My suggestion for going
away from the swiss army function approach is largely based on the
ImageMath help which is, for the most part, a list of operations and their
inputs with little additional information or explanation. The trick may be
writing the documentation in way that allows "?iMath" to be useful and
informative.

On Thu, Feb 12, 2015 at 1:35 PM, bkandel notifications@github.com wrote:

I agree. I think that a "Swiss army knife" function would actually be
nice. It is probably worth starting from scratch so that we don't have to
take with us the past 15 years of ANTs development in ImageMath, though,
and so that we focus on functions that will actually be used. For me, that
means focusing on the low-level image processing routines that can't easily
be done in R and skipping the numeric manipulation (log, neg, +, etc.) and
statistics functions.

A major difficulty is that we don't have a method for having namespaces or
modules in R, like we do in other languages. Ideally, we'd be able to call
ANTsR::imgproc::erode, but we obviously can't do that. I think that
iMath(img, 'erode', 2) is the closest we'll come. We could just put the
possible inputs in the "Details" section of the help (sort of like the ants
ImageMath current help, but ideally more informative).

On 12 February 2015 at 12:14, stnava notifications@github.com wrote:

i've been thinking more about this iMath utility ... here is a relevant
example (i.e. there is precedent in R):

http://topepo.github.io/caret/modelList.html

for iMath to be really useful / interesting, it would have to be
accompanied by a table like this that explains each operation. could be
stored in a dataframe. otherwise, i can imagine an explosion of different
functions that would be ever growing ... any thoughts appreciated.

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

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

[stnava]

i think the caret solution is fine - it's just a dataframe that organizes
the assets

that makes it (relatively) easy to test, maintain and visualize e.g. on the
web

e.g.

OperationName | OperationType | Arguments(free text) | Notes

e.g. ""

OperationName | OperationType | Arguments(free text) | Notes

GetLargestComponent |
LabelOperations | None | returns largest component of a label image

Laplacian |
SpatialFilter | SigmaVector or SigmaScalar | laplacian based on derivative
of gaussian

brian

On Thu, Feb 12, 2015 at 1:47 PM, Jeffrey Duda notifications@github.com
wrote:

I think the documentation is the biggest issue. My suggestion for going
away from the swiss army function approach is largely based on the
ImageMath help which is, for the most part, a list of operations and their
inputs with little additional information or explanation. The trick may be
writing the documentation in way that allows "?iMath" to be useful and
informative.

On Thu, Feb 12, 2015 at 1:35 PM, bkandel notifications@github.com wrote:

I agree. I think that a "Swiss army knife" function would actually be
nice. It is probably worth starting from scratch so that we don't have to
take with us the past 15 years of ANTs development in ImageMath, though,
and so that we focus on functions that will actually be used. For me,
that
means focusing on the low-level image processing routines that can't
easily
be done in R and skipping the numeric manipulation (log, neg, +, etc.)
and
statistics functions.

A major difficulty is that we don't have a method for having namespaces
or
modules in R, like we do in other languages. Ideally, we'd be able to
call
ANTsR::imgproc::erode, but we obviously can't do that. I think that
iMath(img, 'erode', 2) is the closest we'll come. We could just put the
possible inputs in the "Details" section of the help (sort of like the
ants
ImageMath current help, but ideally more informative).

On 12 February 2015 at 12:14, stnava notifications@github.com wrote:

i've been thinking more about this iMath utility ... here is a relevant
example (i.e. there is precedent in R):

http://topepo.github.io/caret/modelList.html

for iMath to be really useful / interesting, it would have to be
accompanied by a table like this that explains each operation. could be
stored in a dataframe. otherwise, i can imagine an explosion of
different
functions that would be ever growing ... any thoughts appreciated.

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

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

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

[bkandel]

I think the c3d documentation (
http://www.itksnap.org/pmwiki/pmwiki.php?n=Convert3D.Documentation) could
be a good model for us.

On 12 February 2015 at 13:47, Jeffrey Duda notifications@github.com wrote:

I think the documentation is the biggest issue. My suggestion for going
away from the swiss army function approach is largely based on the
ImageMath help which is, for the most part, a list of operations and their
inputs with little additional information or explanation. The trick may be
writing the documentation in way that allows "?iMath" to be useful and
informative.

On Thu, Feb 12, 2015 at 1:35 PM, bkandel notifications@github.com wrote:

I agree. I think that a "Swiss army knife" function would actually be
nice. It is probably worth starting from scratch so that we don't have to
take with us the past 15 years of ANTs development in ImageMath, though,
and so that we focus on functions that will actually be used. For me,
that
means focusing on the low-level image processing routines that can't
easily
be done in R and skipping the numeric manipulation (log, neg, +, etc.)
and
statistics functions.

A major difficulty is that we don't have a method for having namespaces
or
modules in R, like we do in other languages. Ideally, we'd be able to
call
ANTsR::imgproc::erode, but we obviously can't do that. I think that
iMath(img, 'erode', 2) is the closest we'll come. We could just put the
possible inputs in the "Details" section of the help (sort of like the
ants
ImageMath current help, but ideally more informative).

On 12 February 2015 at 12:14, stnava notifications@github.com wrote:

i've been thinking more about this iMath utility ... here is a relevant
example (i.e. there is precedent in R):

http://topepo.github.io/caret/modelList.html

for iMath to be really useful / interesting, it would have to be
accompanied by a table like this that explains each operation. could be
stored in a dataframe. otherwise, i can imagine an explosion of
different
functions that would be ever growing ... any thoughts appreciated.

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

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

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

[stnava]

c3d has some nice features but i think the documentation is too unstructured

the data frame is good b/c one can do:

for ( each operation in imath$operationtype == "SpatialFiltering" )
get feature_i

etc ...

this will let us automate things nicely and generally

brian

On Thu, Feb 12, 2015 at 1:56 PM, bkandel notifications@github.com wrote:

I think the c3d documentation (
http://www.itksnap.org/pmwiki/pmwiki.php?n=Convert3D.Documentation) could
be a good model for us.

On 12 February 2015 at 13:47, Jeffrey Duda notifications@github.com
wrote:

I think the documentation is the biggest issue. My suggestion for going
away from the swiss army function approach is largely based on the
ImageMath help which is, for the most part, a list of operations and
their
inputs with little additional information or explanation. The trick may
be
writing the documentation in way that allows "?iMath" to be useful and
informative.

On Thu, Feb 12, 2015 at 1:35 PM, bkandel notifications@github.com
wrote:

I agree. I think that a "Swiss army knife" function would actually be
nice. It is probably worth starting from scratch so that we don't have
to
take with us the past 15 years of ANTs development in ImageMath,
though,
and so that we focus on functions that will actually be used. For me,
that
means focusing on the low-level image processing routines that can't
easily
be done in R and skipping the numeric manipulation (log, neg, +, etc.)
and
statistics functions.

A major difficulty is that we don't have a method for having namespaces
or
modules in R, like we do in other languages. Ideally, we'd be able to
call
ANTsR::imgproc::erode, but we obviously can't do that. I think that
iMath(img, 'erode', 2) is the closest we'll come. We could just put the
possible inputs in the "Details" section of the help (sort of like the
ants
ImageMath current help, but ideally more informative).

On 12 February 2015 at 12:14, stnava notifications@github.com wrote:

i've been thinking more about this iMath utility ... here is a
relevant
example (i.e. there is precedent in R):

http://topepo.github.io/caret/modelList.html

for iMath to be really useful / interesting, it would have to be
accompanied by a table like this that explains each operation. could
be
stored in a dataframe. otherwise, i can imagine an explosion of
different
functions that would be ever growing ... any thoughts appreciated.

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

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

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

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

[stnava]

let me bring up another point - this structure (generically) can be used to
evaluate operations generically. here is an example

http://www.r-bloggers.com/converting-a-string-to-a-variable-name-on-the-fly-and-vice-versa-in-r/

in antsr, we could do

iExpression( list(i1=img1,i2=img2,i3=img3) , xp=" ( i1 + i2 )/ i3 " )

this would require us to define math operations on the raw images or,
alternatively, just convert to vectors before evaluating xp ...

this could be combined with iMath output to produce something very powerful

brian

On Thu, Feb 12, 2015 at 2:04 PM, brian avants stnava@gmail.com wrote:

c3d has some nice features but i think the documentation is too
unstructured

the data frame is good b/c one can do:

for ( each operation in imath$operationtype == "SpatialFiltering" )
get feature_i

etc ...

this will let us automate things nicely and generally

brian

On Thu, Feb 12, 2015 at 1:56 PM, bkandel notifications@github.com wrote:

I think the c3d documentation (
http://www.itksnap.org/pmwiki/pmwiki.php?n=Convert3D.Documentation) could
be a good model for us.

On 12 February 2015 at 13:47, Jeffrey Duda notifications@github.com
wrote:

I think the documentation is the biggest issue. My suggestion for going
away from the swiss army function approach is largely based on the
ImageMath help which is, for the most part, a list of operations and
their
inputs with little additional information or explanation. The trick may
be
writing the documentation in way that allows "?iMath" to be useful and
informative.

On Thu, Feb 12, 2015 at 1:35 PM, bkandel notifications@github.com
wrote:

I agree. I think that a "Swiss army knife" function would actually be
nice. It is probably worth starting from scratch so that we don't
have to
take with us the past 15 years of ANTs development in ImageMath,
though,
and so that we focus on functions that will actually be used. For me,
that
means focusing on the low-level image processing routines that can't
easily
be done in R and skipping the numeric manipulation (log, neg, +, etc.)
and
statistics functions.

A major difficulty is that we don't have a method for having
namespaces
or
modules in R, like we do in other languages. Ideally, we'd be able to
call
ANTsR::imgproc::erode, but we obviously can't do that. I think that
iMath(img, 'erode', 2) is the closest we'll come. We could just put
the
possible inputs in the "Details" section of the help (sort of like the
ants
ImageMath current help, but ideally more informative).

On 12 February 2015 at 12:14, stnava notifications@github.com
wrote:

i've been thinking more about this iMath utility ... here is a
relevant
example (i.e. there is precedent in R):

http://topepo.github.io/caret/modelList.html

for iMath to be really useful / interesting, it would have to be
accompanied by a table like this that explains each operation.
could be
stored in a dataframe. otherwise, i can imagine an explosion of
different
functions that would be ever growing ... any thoughts appreciated.

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

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

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

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

[armaneshaghi]

This is much better (i.e. easier to understand) for users. On a related note, in R would it be possible to perform operator overloading, so that we could just type (antsImage1 + antsImage2)/antsImage3 ?

[jeffduda]

We could implement an antsImage friendly version of formula() so it could
work in a way similar to lm(), making it familiar to users.

On Thu, Feb 12, 2015 at 2:48 PM, Arman Eshaghi notifications@github.com
wrote:

This is much better (i.e. easier to understand) for users. On a related
note, in R would it be possible to perform operator overloading, so that we
could just type (antsImage1 + antsImage2)/antsImage3 ?

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

[bkandel]

Yes! That sounds like a great idea to me. It's already implemented for
mean, var, sd, etc., so we might as well do it for atomic operators.

On 12 February 2015 at 14:48, Arman Eshaghi notifications@github.com
wrote:

This is much better (i.e. easier to understand) for users. On a related
note, in R would it be possible to perform operator overloading, so that we
could just type (antsImage1 + antsImage2)/antsImage3 ?

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

[armaneshaghi]

I think all of these revolve around working on antsImage class more and more. I believe, ImageMath has its functionality inside shell, not in R.

[jeffduda]

It's probably worth thinking about how much we want to enforce physical
space consistency on operations since, while important, this has been
causing headaches in ITK

On Thu, Feb 12, 2015 at 3:00 PM, Arman Eshaghi notifications@github.com
wrote:

I think all of these revolves around working on antsImage class more and
more. I believe, ImageMath has its functionality inside shell, not in R.

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

[armaneshaghi]

there is always a compromise between the comfort of users and developers :-)

[stnava]

glad you guys think this is doable - it will take just a little time,
shouldnt be too difficult .... but not sure who wants to do the first pass?

at the moment, i'd rather review code than write it ....

brian

On Thu, Feb 12, 2015 at 3:08 PM, Arman Eshaghi notifications@github.com
wrote:

there is always a compromise between the comfort of users and developers
:-)

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

[stnava]

@jeffduda there was a recent SetGlobalTolerance flag added to itk that
ameliorates this issue .... it can be set at compile time in cmake ( i
think )

brian

On Thu, Feb 12, 2015 at 3:16 PM, brian avants stnava@gmail.com wrote:

glad you guys think this is doable - it will take just a little time,
shouldnt be too difficult .... but not sure who wants to do the first pass?

at the moment, i'd rather review code than write it ....

brian

On Thu, Feb 12, 2015 at 3:08 PM, Arman Eshaghi notifications@github.com
wrote:

there is always a compromise between the comfort of users and developers
:-)

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

[bkandel]

I already did most of the atomic vectors. Should be pushed as soon as I
finish compiling.

On 12 February 2015 at 15:17, stnava notifications@github.com wrote:

@jeffduda there was a recent SetGlobalTolerance flag added to itk that
ameliorates this issue .... it can be set at compile time in cmake ( i
think )

brian

On Thu, Feb 12, 2015 at 3:16 PM, brian avants stnava@gmail.com wrote:

glad you guys think this is doable - it will take just a little time,
shouldnt be too difficult .... but not sure who wants to do the first
pass?

at the moment, i'd rather review code than write it ....

brian

On Thu, Feb 12, 2015 at 3:08 PM, Arman Eshaghi <notifications@github.com

wrote:

there is always a compromise between the comfort of users and developers
:-)

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

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

[armaneshaghi]

Yes talk is cheap, I will take this on the branch under my name and send a PR for review when done. First start with + and - , and then extend it to * and /

[armaneshaghi]

sorry our message crossed @bkandel . Okay please move on with this...

[bkandel]

OK, I pushed the changes to add atomic vector operations (+ - * / ^ %%) for
antsImages. These operations are in voxel space, not physical space, but I
think that's what most users mean when they say "img1 + img2". If we think
it's worth it, we can go back and do it the ITK way in physical space, but
it's not clear to me that most users would prefer that.

On 12 February 2015 at 15:24, Arman Eshaghi notifications@github.com
wrote:

Yes talk is cheap, I will take this on the branch under my name and send a
PR for review when done. First start with + and - , and then extend it to *
and /

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

[bkandel]

I just added methods for adding numbers to images, and documentation. See
?'+.antsImage' for details. Also added an is.antsImage method for
convenience.

On 12 February 2015 at 16:58, Ben Kandel ben.kandel@sbcglobal.net wrote:

OK, I pushed the changes to add atomic vector operations (+ - * / ^ %%)
for antsImages. These operations are in voxel space, not physical space,
but I think that's what most users mean when they say "img1 + img2". If we
think it's worth it, we can go back and do it the ITK way in physical
space, but it's not clear to me that most users would prefer that.

On 12 February 2015 at 15:24, Arman Eshaghi notifications@github.com
wrote:

Yes talk is cheap, I will take this on the branch under my name and send
a PR for review when done. First start with + and - , and then extend it to

• and /

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

[cookpa]

This will be really useful.

How does division work with masked images? This is a problem in c3d because anything divided by zero becomes NaN, and attempting to mask out NaN after the fact doesn't work because NaN * 0 = NaN.

On Feb 12, 2015, at 6:08 PM, bkandel notifications@github.com wrote:

I just added methods for adding numbers to images, and documentation. See
?'+.antsImage' for details. Also added an is.antsImage method for
convenience.

On 12 February 2015 at 16:58, Ben Kandel ben.kandel@sbcglobal.net wrote:

OK, I pushed the changes to add atomic vector operations (+ - * / ^ %%)
for antsImages. These operations are in voxel space, not physical space,
but I think that's what most users mean when they say "img1 + img2". If we
think it's worth it, we can go back and do it the ITK way in physical
space, but it's not clear to me that most users would prefer that.

On 12 February 2015 at 15:24, Arman Eshaghi notifications@github.com
wrote:

Yes talk is cheap, I will take this on the branch under my name and send
a PR for review when done. First start with + and - , and then extend it to

• and /

�
Reply to this email directly or view it on GitHub
#12 (comment).

�
Reply to this email directly or view it on GitHub.

[bkandel]

I didn't do any special error handling. You can just mask out any parts you
don't care about afterwards. Masking would be img[mask==0] <- 0, so that
should work even for NaN's.

On 12 February 2015 at 18:12, Philip Cook notifications@github.com wrote:

This will be really useful.

How does division work with masked images? This is a problem in c3d
because anything divided by zero becomes NaN, and attempting to mask out
NaN after the fact doesn't work because NaN * 0 = NaN.

On Feb 12, 2015, at 6:08 PM, bkandel notifications@github.com wrote:

I just added methods for adding numbers to images, and documentation. See
?'+.antsImage' for details. Also added an is.antsImage method for
convenience.

On 12 February 2015 at 16:58, Ben Kandel ben.kandel@sbcglobal.net
wrote:

OK, I pushed the changes to add atomic vector operations (+ - * / ^ %%)
for antsImages. These operations are in voxel space, not physical
space,
but I think that's what most users mean when they say "img1 + img2".
If we
think it's worth it, we can go back and do it the ITK way in physical
space, but it's not clear to me that most users would prefer that.

On 12 February 2015 at 15:24, Arman Eshaghi notifications@github.com
wrote:

Yes talk is cheap, I will take this on the branch under my name and
send
a PR for review when done. First start with + and - , and then extend
it to

• and /

�
Reply to this email directly or view it on GitHub
#12 (comment).

�
Reply to this email directly or view it on GitHub.

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

[stnava]

i think exp and log would be good too

[stnava]

ok i did a first pass on a dataframe based documentation / organization of iMath e.g. if you run

library(ANTsR)
i<-antsImageRead( getANTsRData('r16') , 2 )
iMath(i,'ROIStatistics')
# Error in iMath(i, "ROIStatistics") : output of ROIStatistics is csv

you get a (hopefully) meaningful output - ideally iMath would use the dataframe to guide the operations through the appropriate steps s.t. you actually check input and get correct dataframe output in this case but that's not implemented yet ... you can also do:

i<-antsImageRead( getANTsRData('r16') , 2 )
data( "iMathOps", package = "ANTsR", envir = environment() ) #
j  <- 7
op <- as.character( iMathOps$Operation[j] )
k  <- eval( parse( text = toString( iMathOps$Example[j] ) ) )

and get an image output in k ..... regardless, it needs more work but this should give you some ideas of a way we might go. also, all of this is based on accurately/consistently maintaining:

https://github.com/stnava/ANTsR/blob/master/data/iMathOps.csv

see ?iMathOps

[stnava]

probably need to enumerate which operations take an additional image (or more) as input ...

[bkandel]

I think the more we limit this function, the more useful it would be.
Maybe we should poll some users who are not developers on this issue, but I
think that iMath will be most helpful if it's limited to image processing
operations--images and parameters only in, and images out. That would limit
the amount of documentation necessary to read and would prevent confusing
errors. Also, image smoothing and thresholding should be part of this
list.

I think that it would be reasonable to have a separate function for
intensity manipulation (normalization, histogram matching, truncation,
etc.) and one for label propagation. As a user, I wouldn't expect to find
these functions in the same place as dilation/erosion/edge detection.

On 17 February 2015 at 11:38, stnava notifications@github.com wrote:

probably need to enumerate which operations take an additional image (or
more) as input ...

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

[stnava]

@bkandel - your suggestion is basically what's done when one combines the iMath.R and the iMathOps.csv .... the operations are cataloged by type so it's (relatively) easy to see which go together. these could trivially be sorted by type as well ....

agree that there should be an Intensity class of op that is different from filtering ...

the current operation types are:

dd<-read.csv("iMathOps.csv")
levels(dd$OperationType)

• Basic - eg PadImage could not think of a better name
• Disabled ....
• Filter - filter an image eg gradient magnitude
• Intensity - alter intensity histogram in some way
• LabelOp - something on label images specifically, may not return an image
• Metric - maybe should be ImageMetric but eg antsImageMutualInformation
• Morphology - maybe just a filter or just a LabelOp
• NumericSummary - something that returns a scalar or data frame
• Transformation - special operations for transformations e.g generate a reflection matrix

all of this is available in ImageMath ( iMath ) w/o much additional work / maintenance .... splitting these up would indeed be better but would impact many different programs in ANTsR.... resulting code base would not be backward compatible ( maybe not a big deal at this early stage ) ....

regardless, the csv

https://github.com/stnava/ANTsR/blob/master/data/iMathOps.csv

captures the majority of operations that we would need to be available in antsr to help us do studies of asymmetry, prediction, segmentation etc that we all have on our hands .....

the major steps are:

• implement iMath.cpp st it can be used generally
• wrap and document different iMath functionality
• test existing code base given whatever changes are above .... this means documenting, compiling, building manual and vignettes - shortest (in code) way to do this is:
• roxygen2::roxygenize()
• devtools::check()

anyway, i implemented the "old school" approach as an example for all to see and because progress was minimal ... am sort of chomping at the bit to move on to the next stage ( cran submission ) and this is, afaik, the major (user obvious) design issue at this moment.

[armaneshaghi]

@stnava Should there be a separate vignette for this? I prefer imath.Rmd for example. Happy to work on this.

[stnava]

That would be a very helpful project ....

Just be aware that examples should be fast and that design may change. So
some maintenance will be required, short term ....
On Feb 17, 2015 12:17 PM, "Arman Eshaghi" notifications@github.com wrote:

@stnava https://github.com/stnava Should there be a separate vignette
for this? I prefer imath.Rmd for example. Happy to work on this.

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

[bkandel]

It looks like iMath currently just wraps ImageMath. If the only difference
between ImageMath and iMath is how many functions are available, what needs
to be reimplemented in iMath.cpp? Shouldn't we just keep ImageMath.cpp?

On 17 February 2015 at 14:23, stnava notifications@github.com wrote:

That would be a very helpful project ....

Just be aware that examples should be fast and that design may change. So
some maintenance will be required, short term ....
On Feb 17, 2015 12:17 PM, "Arman Eshaghi" notifications@github.com
wrote:

@stnava https://github.com/stnava Should there be a separate vignette
for this? I prefer imath.Rmd for example. Happy to work on this.

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

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

[stnava]

We only use about 10% of the function and it adds to compile time. So
ideally we would limit the functions that we build to those that we use.
On Feb 17, 2015 12:36 PM, "bkandel" notifications@github.com wrote:

It looks like iMath currently just wraps ImageMath. If the only difference
between ImageMath and iMath is how many functions are available, what needs
to be reimplemented in iMath.cpp? Shouldn't we just keep ImageMath.cpp?

On 17 February 2015 at 14:23, stnava notifications@github.com wrote:

That would be a very helpful project ....

Just be aware that examples should be fast and that design may change. So
some maintenance will be required, short term ....
On Feb 17, 2015 12:17 PM, "Arman Eshaghi" notifications@github.com
wrote:

@stnava https://github.com/stnava Should there be a separate
vignette
for this? I prefer imath.Rmd for example. Happy to work on this.

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

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

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

[stnava]

am going to make another pass through iMath dox and restrict to just "image in, image out" operations, possibly with an attempt to handle multiple image inputs ... will update later.