 |
 |
I can't say I find this very consistent, in my opinion the mesh should have the same coordinates as the image, but as long as the documentation is clear and correct, it's fine. Thanks for letting me know. Cheers, Marc On Thu, 5 Feb 2009 17:43:08 +0000, Mark Jenkinson <[log in to unmask]> wrote: >Hi Again, > >We've just looked thoroughly at this issue and have >had to change our minds about what the coordinates >will be. Because the mesh files can exist independently >of image files, and do not in themselves contain information >on the coordinate system handedness, then we have >ended up opting to leave the coordinates that are stored >in the mesh files in their current format. This is the only >consistent way that we can make sure that swapping the >original image's coordinate handedness won't affect the >mesh outputs and that things will stay consistent. > >This means that the coordinates in the mesh file are simply >scaled versions of the voxels for radiologically ordered >images, but swapped in x for neurologically ordered images. >We have modified the html documentation for betsurf >to reflect this. The relevant paragraph is below. > >All the best, > Mark > >"The .vtk and .off Geomview mesh files contain mm co-ordinates. If the >image has radiological ordering ( see fslorient ) then the mm co- >ordinates are the voxel co-ordinates scaled by the mm voxel sizes. If >the image has neurological ordering the y and z co-ordinates are the >same as for radiological ordering, but the x co-ordinates will be >inverted ( x_mm = ( n - 1 - x ) * x_dim ) where n is the number of >voxels in the x-direction, x is the voxel co-ordinate and x_dim is the >voxel size in mm." > > > > >On 3 Feb 2009, at 16:19, Marc Lalancette wrote: > >> Great. That does make a lot of sense. >> Thanks for taking the time to help. >> Cheers, >> Marc >> >> On Mon, 2 Feb 2009 16:23:33 +0000, Mark Jenkinson >> <[log in to unmask]> wrote: >> >>> Hi, >>> >>> We will either make them consistent with the FSLView >>> voxel coordinates or with the FSLView mm coordinates. >>> Probably the former. We are trying to make sure that >>> these are the only two coordinates which people will >>> ever need to deal with. >>> >>> This is the only list for FSL and we make all official >>> announcements here. >>> >>> All the best, >>> Mark >>> >>> >>> On 2 Feb 2009, at 16:05, Marc Lalancette wrote: >>> >>>> Thanks Mark, >>>> >>>> So once it's fixed, are the coordinates supposed to be voxel order >>>> (as they >>>> are stored in the file) times voxel size or real world coordinates >>>> as >>>> specified by q/sform but with the origin in the "negative" corner? >>>> Both >>>> seem a bit strange to me. I'd have stuck with either raw voxel >>>> order or >>>> q/sform coordinates. Might be something to consider, perhaps as an >>>> option. >>>> >>>> Also, there isn't another mailing list for official announcements, >>>> like new >>>> patches or releases, is there? >>>> >>>> Cheers, >>>> Marc >>>> >>>> >>>> On Fri, 30 Jan 2009 19:36:56 +0000, Mark Jenkinson <[log in to unmask] >>>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> This does indeed look like a bug that has slipped through the >>>>> net when we were migrating all functionality to work with either >>>>> left or right-handed coordinate systems. We will fix it in the >>>>> next patch. >>>>> >>>>> Thanks for letting us know. >>>>> All the best, >>>>> Mark >>>>> >>>>> >>>>> On 28 Jan 2009, at 21:33, Marc Lalancette wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> While trying to carefully follow coordinate changes from start to >>>>>> finish, I >>>>>> found out that the .off mesh produced by bet -A has coordinate >>>>>> axes >>>>>> aligned >>>>>> with LAS regardless of the voxel order in the source .nii file. >>>>>> The >>>>>> betsurf >>>>>> documentation however states that the coordinates should be "the >>>>>> integer >>>>>> voxel co-ordinates multiplied by the voxel size values". That's >>>>>> not >>>>>> very >>>>>> clear since it doesn't say which voxel coordinates, but I don't >>>>>> see >>>>>> how it >>>>>> could mean LAS regardless of voxel order. >>>>>> >>>>>> Just to be clear, here is what I did: >>>>>> >>>>>> My dcm files are stored with LPS voxel order. >>>>>> I convert them to NIfTI format using dcm2nii which can produce 2 >>>>>> ouput: the >>>>>> "regular" one has voxel order LAS and the "reoriented" one has >>>>>> voxel >>>>>> order >>>>>> RAS (according to the voxel coordinates shown in fslview and also >>>>>> verified >>>>>> in Matlab). Both of these NIfTI files have correct header info to >>>>>> produce >>>>>> RAS coordinate axes (verified in fslview). >>>>>> Now, if I use bet -A on both of these, the .off mesh files will >>>>>> both >>>>>> have >>>>>> LAS coordinates. (I only looked at inner skull meshes.) >>>>>> >>>>>> So it seems the documentation is misleading or there is a bug. >>>>>> >>>>>> Cheers, >>>>>> Marc >>>>>> >>>> >>