real space coordinates from context manager about papaya

[rii-mango]

I've added a couple of new convenience methods to convert coordinates between spaces which should help. Update your build then see the new version of ctxManager.prototype.drawToViewer() at https://github.com/rii-mango/Papaya/wiki/How-To-Make-a-Context-Manager

[akeshavan]

Thanks!

[akeshavan]

I don't think viewer.getWorldCoordinateAtIndex function is doing what I think it does - it seems to always return integers for world coordinates - but this isn't the case when I open freeview or fslview and locate the same point. Should I be using a different method?

[rii-mango]

Here's the code for that function:

papaya.viewer.Viewer.prototype.getWorldCoordinateAtIndex = function (ctrX, ctrY, ctrZ, coord) {
    coord.setCoordinate((ctrX - this.volume.header.origin.x) * this.volume.header.voxelDimensions.xSize,
        (this.volume.header.origin.y - ctrY) * this.volume.header.voxelDimensions.ySize,
        (this.volume.header.origin.z - ctrZ) * this.volume.header.voxelDimensions.zSize);
    return coord;
};

The returned coordinate would have a fractional part if either the origin or voxel dimensions have a fractional part. Can you share the image you're working with?

[akeshavan]

I have tracked down the issue to this method here:

papaya.volume.Transform.hasRotations = function (mat) {
    var decomp, epsilon, rotX, rotY, rotZ;

    if (mat !== null) {
        decomp = papaya.volume.Transform.decompose(mat);
        epsilon = 0.01;

        rotX = (Math.abs(1 - (Math.abs(decomp[3]) / 90.0)) % 1);
        rotY = (Math.abs(1 - (Math.abs(decomp[4]) / 90.0)) % 1);
        rotZ = (Math.abs(1 - (Math.abs(decomp[5]) / 90.0)) % 1);

        return ((rotX > epsilon) || (rotY > epsilon) || (rotZ > epsilon));
    }

    return false;
};

Why is epsilon set to 0.01? I have a file with rotation = 0.008, and coordinates are slightly off. I'm about to set it to something really low, but I'm curious if there was a reason for this epsilon. Thanks!

[rii-mango]

That function hasRotations() is just to check if the NIFTI transform has an image transform mixed into it. That is, the NIFTI transform usually stores basic orientation/origin information, but it can also have an image transform (e.g., rotate image into some registered space). Papaya tries to pull out just the orientation information, but if there are rotations, it can't. So that epsilon value is just to check if the NIFTI transform contains an image transform. (Generally, those rotation values should all be 0.)

If a NIFTI image does contain an image transform, then it is best viewed in "world mode" because "image mode" relies on knowing that data orientation. Mango works more or less the same way, except that it automatically switches you to "world mode" when it encounters one of these images. I will probably make that change in Papaya soon.

Not sure if this helps or just makes the matter more confusing. :-) At any rate, let me know if you encounter images that don't work as expected.

[rii-mango]

I'm going to close this up now. Let me know if you have any other issues.

[fancyoung]

There is another problem, z value will be always is multiples of sliceSize, but not real z.

For example, one of the image Image Position Patient tag is [199.5,171,13], slice spacing is 5mm,
the coord.z result will be 3*5 = 15.

Because both this.volume.header.origin.z and ctrZ are always typeof int.