Hi,

I have noticed that, when visualised through the "triplanar" viewer, the 3D stacks look different if any of the space directions in the NRRD file is smaller than one.

One stack, with pixel size set to 0.8, appears turned by 180 degrees with respect to the same stack with pixel size set to 1. If I click on a pixel and look at the RAS value of its coordinate, a NaN is displayed. This appears to be happening any time one of the space directions is smaller than one.

Am i not supposed to use a pixel size which is smaller than one or there is a bug in the viewer?

I am also wondering whether this only happens in the "triplanar" or if it affects also the way CMTK interprets the coordinates when computing and applying the transformations...

Thanks,

Tommaso

Hi Tommaso -

I very much doubt there's a problem because of pixel size smaller than 1; as a matter of fact, CMTK was mostly developed for human (e.g., MRI, CT) images, where the pixel size is below 1 (mm) more often than not.

That said, there's of course always a chance that there is some bug.

Could you post the Nrrd header for your files here so I can take a look what might be the problem? (If you have detechad file headers, simply post the .nhdr files; for attached headers, copy & paste the text portion from the beginning of the .nrrd file).

Best,
  Torsten

Dear Torsten,

Here is the header of the .nrrd that creates problems:

NRRD0004
type: uint16
dimension: 3
space: right-anterior-superior
sizes: 713 788 20
space directions: (0.8,0,0) (0,0.8,0) (0,0,8)
kinds: domain domain domain
encoding: raw
endian: little
space origin: (0,0,0)

This one instead is displayed fine:

NRRD0004
type: uint16
dimension: 3
space: right-anterior-superior
sizes: 713 788 20
space directions: (1.5,0,0) (0,1.5,0) (0,0,8)
kinds: domain domain domain
encoding: raw
endian: little
space origin: (0,0,0)

Best,

Tommaso

Hi Tommaso -

Thanks for the headers. Unfortunately, I cannot reproduce your problem. When I read volumes with the two different pixel sizes, they both show up correctly, and I get no NaNs clicking on pixels either.

Here's another thing to try - could you run the following command on each of the two volumes and post the resulting output here:

describe --read-ras VOLUME.nrrd

where "VOLUME" is whatever file name your volume uses.

This tool internally uses the exact same library functions to read and reorient the image data, so perhaps that will shed some more light on what's going on.

Now, one other thing - while I have never seen  or heard of the problem you described, can you just confirm that you are using the latest version of CMTK?

Best,
  Torsten

Hi,

Here is what i get with pixel size=1

File format: Nrrd image file [File].
713 x 788 x 20 voxels
Original image orientation: LPS
Uniform volume
1.000000 x 1.000000 x 8.000000 [] voxel size
712.000000 x 787.000000 x 152.000000 [] volume size
Volume origin (0.000000,0.000000,0.000000)

Image-to-physical matrix:
1.000000 0.000000 -0.000000 -712.000000
-0.000000 1.000000 -0.000000 -787.000000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000

And here with pixel size = 0.1

File format: Nrrd image file [File].
713 x 788 x 20 voxels
Original image orientation: LPS
Uniform volume
0.100000 x 0.100000 x 8.000000 [] voxel size
71.200000 x 78.700000 x 152.000000 [] volume size
Volume origin (0.000000,0.000000,0.000000)

Image-to-physical matrix:
1.000000 0.000000 -0.000000 -71.200000
-0.000000 1.000000 -0.000000 -78.700000
0.000000 0.000000 1.000000 0.000000
0.000000 0.000000 0.000000 1.000000


A part from the obvious scaling, the output looks exactly the same. I am reassured since I guess this means that the transformations are computed in the same reference frame.

I am currently using version 3.2.2 for Linux, I will try to update and tell you whether the problem still appears.

Thank you,

Best,

Tommaso

Yeah, that looks pretty much like it should. In other words, unfortunately, still no idea why triplanar should trip up with these data.

Your CMTK version should also be recent enough to not have any weird long-fixed bugs, so I doubt an update will help.

That said, though, did you build from source yourself, or install a precompiled package from NITRC? I have on occasion seen rather unintuitive bugs arising from unexpected (or inconsistent) build configuration.

Torsten