@Atlasize labels messed up

AFNI Message Board
1

Hello everyone,

while waiting until official combined macaque SARM+CHARM atlas is produced, I tried to make an ad-hoc combined version (“FARM”) to be able to have a first look at my resting state data.

I put together CHARM + SARM while adding 1000 to SARM keys. I was ensured that there was no spatial overlap between SARM & CHARM, so I did not check for that. I made a new key file from SARM and CHARM (the former with key values increased by 1000) and applied them to the new atlas with @Atlasize. I also added a prefix for SARM labels because there is overlap between the atlases in this area.


3dcalc -a ${CHARMfile}  \
       -b ${SARMfile} \
       -expr 'a + b + 1000*bool(b)' \
	   -prefix ${FARMfile}  \
	   -overwrite

#creating new key file here


@Atlasize -dset ${FARMfile}+tlrc \
           -lab_file $FARMkey_file 1 0 \
           -longnames 2 \
           -atlas_name FARM

The key file looks like this, I thought it would be good for @Atlasize:


1 Frontal Frontal_Lobe
2 ACgG anterior_cingulate_gyrus
3 ACC anterior_cingulate_cortex
4 area_32 area_32
5 area_25 subgenual_cortex
6 area_24 area_24
[...]
242 V3v ventral_visual_area_3
243 V2 visual_area_2
244 possibly_V2 possibly_part_of_visual_area_2
245 clearly_V2 clearly_part_of_visual_area_2
246 V1 primary_visual_cortex
1001 scx_tel telencephalon
1002 scx_LVPal lateral_and_ventral_pallium
1003 scx_LPal lateral_pallium
1004 scx_Cl claustrum

I was a little concerned because @Atlasize left behind two temp files and a file called LABEL_TABLE_NOT_SET. But the resulting atlas looked good, i.e. it displayed correct keys and labels in AFNI GUI the define overlay panel.

So I went on, but when I used the combined FARM atlas to generate ROI-based functional correlations, the labels were (partially) messed up.
And 3dNetCorr said:


++ Labelling regions internally.
++ Have labeltable for naming things.
*+ WARNING: Have label_table, but at least one ROI in your data set
        does NOT have an entry value.

I went back and looked at 3dinfo -labeltable for the combined FARM atlas and it looked wrong, mixed up labels, keys, and long names


<VALUE_LABEL_DTABLE
  ni_type="2*String"
  ni_dimen="561" >
 "anterior_cingulate_cortex" "4"
 "area_12m/o" "medial_and_orbital_area_12"
 "medial_agranular_insular_region" "40"
 "posterior_lateral_agranular_insula_area" "44"
 "PM" "premotor_cortex"
 "83" "PMdr"
[...]

compare to CHARM:

<VALUE_LABEL_DTABLE
ni_type="2*String"
  ni_dimen="246" >
 "11" "MCC"
 "38" "OFa-p"
 "40" "lat_Ia"
 "67" "area_46f"
 "96" "SPL"
 "106" "PEa"
[...]

or SARM


<VALUE_LABEL_DTABLE
  ni_type="2*String"
  ni_dimen="318" >
 "9" "Pir"
 "10" "MPal"
 "47" "CdT"
 "51" "VStr"
 "88" "LH"
[...]

So it seems that my idea of combining the atlases and applying labels via @Atlasize was wrong. How should I do it correctly?

And, incidentally:
If the labels were messed up in the FARM atlas, why did AFNI/Define Overlay display them correctly?
How long names work, if they are not included in the labeltable as returned by 3dinfo?

2

Update: making a 2-column key file and using:


@Atlasize -dset ${FARMfile}+tlrc \
           -lab_file ${FARMkey_file} 1 0 \
           -atlas_name FARM

makes it work fine even if without long names. If am still curious how to add long names correctly, but it’s less of s pressing issue now

3

Hi, Pawel-

I have only ever made 2 column files with @MakeLabelTable…

Note: SARM and CHARM do overlap. I guess some of the continued work on merging them involves this overlap; naming; numbering; and potentially more things.

If it were me, I would wait for the full, merged atlas from the SARM+CHARM people. If you have questions about where they are at with that, Adam Messinger would be the person to email, I think.

–pt

4

Hi Paul,

I’ve been in touch with Adam. Yes there is overlap, I found it in the meantime. I misread an earlier email from Adam. It will add handling that overlap to my code. I agree that for proper analysis I need to wait until Adam does it properly, this is just to have a quick look at the data.

Curious thing about long names, as this feature is documented in @Atlasize help. I am wondering now if the overlap, which generates spurious keys from adding non-zero CHARM voxels to non-zero SARM voxels, was the reason for the long names failing. Once I add overlap handling, I’ll know!

5

Pawel-

Just to note some 3dcalc-isms that might help in your merging (though I reiterate that I am not recommending going down this route):

This would merge 2 dsets, DSET1 and DSET2, giving DSET1 "preference in the merging—that is, take DSET1’s values, and in places where DSET1 is zero, fill in with DSET2’s values:


3dcalc \
    -a DSET1 \
    -b DSET2 \
    -expr 'a+ not(a)*b' \
    -prefix DSET_MERGED

This would do the same thing, offsetting DSET2’s values by some constant like 500, with that chosen under the assumption that the max of DSET1 is less than 500 (which could be found with, say, “3dinfo”):


3dcalc \
    -a DSET1 \
    -b DSET2 \
    -expr 'a+ not(a)*(500+b)' \
    -prefix DSET_MERGED

–pt

6

Thanks!

The solution I used in the meantime was far less elegant:


-expr 'a  + (b + 1000*bool(b)) * not(equals(bool(a)+bool(b), 2))'

maybe because I built on my original


-expr 'a  + b + 1000*bool(b))

(which assumed no overlap) and I did not think of streamlining.

By the way, avoiding overlap does not fix the problem with the longnames messing up the label table.

7

Hi Pawel,

You’re keeping us on our toes. I’ll take a look into the long names issue to see where there’s a problem.

8

Thank you, Daniel!

9

There was indeed a bug regarding long names for atlases. I’ve updated the source code for it, and it should be in the next distribution. Alternatively, you can fetch the tcsh scripts that were changed (@Atlasize an @MakeLabeltable) in our github repository.

10

… and we did a build last night (Apr 5, 2021), so you can run “@update.afni.binaries -d” to get the new+improved version, which should now be (“afni -ver”):

Apr 5 2021 (Version AFNI_21.1.00 ‘Domitian’)

–pt

11

Thanks!

Pawel