Using an alternative atlas

[MohammadHosseinMaleki]

Hello, It was a real pleasure working with this tool, I just have one question, how can we adjust it to use another atlas for labeling, I have done my analysis with the FSL Harvard Oxford (164 region), and I want to use the same atlas for labeling, could you please guide me through this?

[paulcbogdan]

Hi, to handle 164 ROIs, you will need to create a new dictionary for the idx_to_label parameter and an (n, 3)-sized list of lists/tuples for the coords parameter.

For instance, if the 0th ROI had the "FP" label (MNI coordinate: [0, 68, 6]) and the 1st ROI had the "IFG" label (coordinate: [44, 32, 0]), then your dictionary would start:

idx_to_label = {0: 'FP', 1: 'IFG'}
coords = [[0, 68, 6], [44, 32, 0]]

You would need to expand this for all 164 ROIs or so (i.e., make a dictionary of length 164 and a list of length 164). The first example in the README shows this process going up to 8 ROIs.

However, just a heads-up: The Harvard-Oxford atlas contains 69 labels for cortical and subcortical areas, right? If so, I'm not sure if you'd be able to fit them all neatly on the chord diagram (i.e., if you're plotting 69 segments, then each one would be tiny and there wouldn't be any space for the text).

[MohammadHosseinMaleki]

Dear Mr. Bogdan,

I hope this email finds you well. Firstly, I want to extend my heartfelt gratitude for your prompt and thorough response, as well as for taking the time to assist me with this matter. Your guidance has been invaluable, and I truly appreciate your support.

I understand from your instructions that creating a new dictionary for the idx_to_label parameter and generating an (n, 3)-sized list of lists/tuples for the coords parameter is the recommended approach for handling multiple ROIs. Your example was clear and concise, and I will certainly proceed with implementing it accordingly.

However, I wanted to inquire about the possibility of modifying the code to accommodate our own atlas file, similar to how it interacts with the Yeo atlas. While I understand that the package is designed for the Yeo atlas, I was curious if there might be a feasible way to adapt the code to work with our specific atlas.

Do you believe it would be feasible to customize the code in such a manner, or do you still recommend proceeding with manually developing the dictionary as per your initial guidance?

Once again, thank you immensely for your assistance and for shedding light on this matter. I look forward to your insights and guidance.

Warm regards,

Mohammad Hossein

On Sun, Feb 18, 2024 at 7:54 PM Paul Bogdan @.***> wrote:

Hi, to handle 164 ROIs, you will need to create a new dictionary for the idx_to_label parameter and an (n, 3)-sized list of lists/tuples for the coords parameter.

For instance, if the 0th ROI had the "FP" label (MNI coordinate: [0, 68, 6]) and the 1st ROI had the "IFG" label (coordinate: [44, 32, 0]), then your dictionary would start:

idx_to_label = {0: 'FP', 1: 'IFG'}coords = [[0, 68, 6], [44, 32, 0]]

You would need to expand this for all 164 ROIs or so (i.e., make a dictionary of length 164 and a list of length 164). The first example in the README shows this process going up to 8 ROIs.

However, just a heads-up: The Harvard-Oxford atlas contains 69 labels for cortical and subcortical areas, right? If so, I'm not sure if you'd be able to fit them all neatly on the chord diagram (i.e., if you're plotting 69 segments, then each one would be tiny and there wouldn't be any space for the text).

— Reply to this email directly, view it on GitHub https://github.com/paulcbogdan/NiChord/issues/2#issuecomment-1951376400, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGHX2MBSN4R5ZMZRECKRY5DYUITMRAVCNFSM6AAAAABDODBMFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJRGM3TMNBQGA . You are receiving this because you authored the thread.Message ID: @.***>

[paulcbogdan]

Hi Mohammad, sorry for this much slower response! I think you should just pursue the dictionary route. This is certainly the easiest way to accomplish what you seem to be looking for.

I'm not sure what you mean by adapting the code to work with the atlas you are using. The only change that I could see would be adapting get_idx_to_label to accept a different atlas argument. It currently only has the yeo atlas setup for it. However, this could be changed to have other atlases built in. If you end up doing this and you want to incorporate another atlas in the code, please let me know. I would happily pull such a change, but I don't have time to work on something like this myself right now (particularly, as the dictionary route is always there, so this type of modification isn't essential).