Per-vessel outputs swapped in some subjects

[winokl]

I am working with vessel-encoded ASL using OXASL and have observed that some participants show incorrect vessel allocation in the outputs. The veasl folder consistently contains vessel*/asl_data.nii.gz corresponding to the correct vessel data. However, in certain participants the basil_vessel* folders contain data corresponding to the wrong vessels. Often data for vessel 1<>3 and 2<>4 are swapped between these two folders. Is there a fix for this?

[mcraig-ibme]

Hi, I was trying to see if I could reproduce this on a test data set, however I'm not sure exactly which folders you're referring to. In the current version of oxasl_ve, there are basil_vessel folders which contain the modelling output for each vessel, and output_vessel which contain the processed and calibrated output from these. They should correspond to each other.

I have some older output which suggests that previous versions might have stored the basil output in veasl/vessel folders - but you should not have both at the same time. Have you previously run older versions of the code - could these folders be leftovers?

If possible, I'd be happy to try to reproduce this using an example subject if you are able to share the data for one of them.

[winokl]

Hi, thank very much for your quick reply.
To make sure I was working with the most recent oxasl version, I updated oxasl and re-ran the subject with a new output folder. Indeed, veasl/vessel folders do not exist in the new output and you were right that the veasl/vessel folders in my previous output folder were older than the other files and must have been from a previous run.

My remaining question is about the vessel numbering. In the newer version, the vessel outputs seem to map differently compared with older runs. For this subject (and a few others), vessel 1 appears to correspond to the right vertebral, vessel 2 to the left vertebral, vessel 3 to the right carotid, and vessel 4 to the left carotid. In most subjects (and I believe also in this subject’s older oxasl output), the ordering is the more typical pattern: 1 = right carotid, 2 = left carotid, 3 = right vertebral, 4 = left vertebral.

I’d be very happy to share this subject’s data via Oxford’s OneDrive if that would help to reproduce the issue.

[mcraig-ibme]

Hi, thanks for that, glad it's sorted part of the issue. Offhand I would expect the vessel outputs to correspond to the ordering of the initial vessel locations in the veslocs file. These are typically used as a prior so it is possible that the inference may swap locations - try looking in the output veslocs file in the veasl folder and see if the co-ords are significantly different from the input. If this doesn't explain it then contact me at martin.craig@nottingham.ac.uk and we can arrange to share some data

[winokl]

Hi, that seems to be exactly what happened, thank you! In the subjects with the swapped vessels, the veslocs file in the veasl folder differs much more from the input, whereas in the other subjects the output veslocs remain quite similar to the initial locations. Is there a way to prevent or correct this swapping behaviour?

Thanks again for your help.

[mcraig-ibme]

You could try tightening the prior, i.e. not allowing the coords to change as much using these options:

--xy-std
--rot-std

These are the std.dev of XY shift and rotation priors - the default is 1 for XY and 1.2 for rot, so reducing these should make the co-ords stick closer to the original values

There is also the option of --infer-loc=none which will simply prevent the locations being inferred at all - they will stay in the initial positions. The default is to infer a rigid body transform. I'm surprised that you are getting swaps with a rigid transform actually as that would imply a big rotation - unless you are using --infer-loc=xy which allows the co-ords to vary directly. If that was the case then --infer-loc=rigid might help.

It would be interesting to see the before and after veslocs for one of the subjects that's getting swapped to see what's actually happening here.