I understand your choice and I am fine with it, but just for the discussion
here is my point of view.
It's true that s/qforms are not necessarily set, but that would be a problem
with the program or process that was used to make the files. I think it is
justifiable to assume at least one of these are present and if not then to
use whatever default you choose.
I just feel that the mesh output should be consistent with the other
outputs, i.e. the image files. You already have to deal with all these
coordinate issues when writing the image files, and although the mesh is not
intrinsically associated with a coordinate system as you say, I would think
it is implicitely associated with that of the source and other output
images. I just see your choice as introducing a new system for the mesh
instead of sticking with the one that should already be present in the
source and that we can see and use in FSLView.
But anyway, that's just my two cents. I'm happy as long as I know what's
going on and I can convert appropriately.
Have a nice weekend,
Marc
On Fri, 6 Feb 2009 16:40:02 +0000, Mark Jenkinson <[log in to unmask]> wrote:
>Hi,
>
>The problem is that the mesh is not intrinsically attached to an
>image, so the mesh needs to represent the same information
>whether the image uses a left-handed or right-handed coordinate system.
>Therefore our only choices are to use the qform/sform (which can
>change and is not always set - which is the real problem) or to
>go with a system that is insensitive to the handedness of the
>coordinate system. The voxel coordinate are not insensitive, so
>we have decided that we need to do what we've said. I cannot
>see what else we could do that would be "more consistent"
>across images that are the same except for the order of the
>storage (which is encoded in the handedness).
>
>All the best,
> Mark
>
>
>
>On 6 Feb 2009, at 16:24, Marc Lalancette wrote:
>
>> 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
>>>>>>>>
>>>>>>
>>>>
>>
|