Checking existence of a Format or FileType

Questions about BrainVisa usage and installation

Moderators: denghien, riviere

Post Reply
pron.a
Posts: 22
Joined: Mon Feb 22, 2016 10:09 am

Checking existence of a Format or FileType

Post by pron.a »

Hello dear Brainvisa team,

I am currently working on a Brainvisa toolbox and I have to define "new" FileType and Format. It appears that depending on the Brainvisa version used (up-to-date standard bug_fix or not) some of the Format or FileType may already exist in the builtin types file. How can I check that the Format exists or not and declare my new Format or FileTypes only if they were not previously declared ?

Alex
User avatar
riviere
Site Admin
Posts: 1361
Joined: Tue Jan 06, 2004 12:21 pm
Location: CEA NeuroSpin, Saint Aubin, France
Contact:

Re: Checking existence of a Format or FileType

Post by riviere »

Hi,
I'm sorry I completely missed your question...
You can query DiskItem types using the function neuroDiskItems.getDiskItemType().
You can use it from a types file using directly getDiskItemType() there, the types files are actually regular python files which are executed when loading toolboxes.
Denis
pdeman
Posts: 39
Joined: Thu Sep 17, 2015 4:09 pm
Location: moving sometimes

Re: Checking existence of a Format or FileType

Post by pdeman »

Hi,
but the format and type are declared in brainvisa.../brainvisa/toolboxes/toolboxName/types/xxx.py
and brainvisa.../brainvisa/toolboxes/toolboxName/hierarchies/brainvisa-3.2.0/yyy.py

when does these files execute ? at shared database update ?

so in the xxx.py and yyy.py I should do an from brainvisa.data import neuroDiskItems
and if neuroDiskItems.getDiskItemType("PET") == False:
FileType("PET","3D Volume")

something like that ?

I tried to pdb but don't know why, I put some print and pdb in these xxx.py and yyy.py and it never print or pdb.

"update"
if I restart Brainvisa it goes in it.
so I did in xxx.py:

Code: Select all

from brainvisa.data import neuroDiskItems
allTypes = neuroDiskItems.getAllDiskItemTypes()
allTypesStr=[x.name for x in allTypes]

if "PET" not in allTypesStr:
   FileType("PET","3D Volume")
except I guess it will works only if brainvisa execute first the nuclear toolbox types insertion and then my toolbox types insertion.
if it does the inverse, except if the nuclear toolbox did something similar it will still fail.

can't test as I don't have it.
Last edited by pdeman on Tue Mar 20, 2018 1:02 pm, edited 1 time in total.
User avatar
riviere
Site Admin
Posts: 1361
Joined: Tue Jan 06, 2004 12:21 pm
Location: CEA NeuroSpin, Saint Aubin, France
Contact:

Re: Checking existence of a Format or FileType

Post by riviere »

Hi Pierre,
The types/formats files are read at startup when you run brainvisa, or when you reload toolboxes, not when updating databases.
You can get the list of all types (getAllDiskItemTypes()) and formats (getAllFormats()), and check if one of them is present in the list:

Code: Select all

from brainvisa.processes import *
if "PET" in [x.name for x in getAllDiskItemTypes()]:
    # do something
Not sure however that you can do that within a types file, because it would probably result in circular importation of modules.
If I understand you want to define the PET type if it is not defined. It is normally defined in the nuclar_imaging toolbox, which is currently not released publicly. Maybe you could try something like:

Code: Select all

try:
    include('nuclearImaging')
except:
    FileType("PET","4D Volume")
    # etc
(I haven't tried, actually)
Denis
pdeman
Posts: 39
Joined: Thu Sep 17, 2015 4:09 pm
Location: moving sometimes

Re: Checking existence of a Format or FileType

Post by pdeman »

Hi,

yes for now I only have problem with the nuclear imaging toolbox. (actually some users because I don't have it myself so I can't test).
but we declare, PET, FLAIR, FGATIR etc ...
we may have more conflicts one day.

so for now I did the "PET" in getAllDiskItemTypes stuff, in my type file. (previous post)

what do you mean by circular importation of modules ?
I don't reimport module I think.

my problem is if brainvisa load my types/format first, (so it will declare PET) and then load types/formats from the nuclear toolbox, it will crash again because, I guess, the nuclear toolbox doesn't have the "if PET already declared" stuff

is there a way to specify types/format reading order when running brainvisa ?

my second problem would be the hierarchies files.
I guess the nuclear_imaging toolbox add something about the PET format in it.

and we do as well. hopefully there is not much difference between our hierarchies and theirs, but it something I would have to check
User avatar
riviere
Site Admin
Posts: 1361
Joined: Tue Jan 06, 2004 12:21 pm
Location: CEA NeuroSpin, Saint Aubin, France
Contact:

Re: Checking existence of a Format or FileType

Post by riviere »

what do you mean by circular importation of modules ?
I mean that to use getAllDiskItemTypes, you need to import brainvisa.processes, and the list of diskitems should be already here. For that, brainvisa.processes needs to import itself all types files. Then your type file imports processes, processes imports your types file (even indirectly), and the snake swallows its tail. At the end modules get incompletely loaded and the whole software doesn't work correctly.
I don't reimport module I think.
But then you're not sure all types have been loaded yet, because you are in a file which is read while building the types list. To solve this dependency problem, types files in brainvisa use the (brainvisa) function "include()", that's why I suggested it.

I realize that these basic neuroimaging types are used in several independent toolboxes, so I guess in later releases we should probably define most of them in a central place in Axon, not in toolboxes, even when they are not used yet. Either in builtin, or in a separate file at the same location, let's say "neuroimaging" for instance. But for now this is not done this way, so you will have to use the trick above.

Denis
pdeman
Posts: 39
Joined: Thu Sep 17, 2015 4:09 pm
Location: moving sometimes

Re: Checking existence of a Format or FileType

Post by pdeman »

I don't have any error anymore with the filetype declaration.

but I realize that to make something clean it's gonna be difficult ...

for us, PET was a "final" filetype.
in the nuclear toolbox it seems to be more like a filetype, having subtype.
and what would correspond to our PET would be something like their "Normalized PET" or "Interpolated PET" I guess.

I was thinking that I could modify my code in order to "load" automatically the patient partial volume corrected pet from the nuclear imaging toolbox for those who have it. and the "normal pet" for those who haven't.

but as we already have hundreds of patient in our database, it's gonna be really difficult. I guess I would have to change all my "PET" to match their input PET. modify my hierarchy in my database.
and then in my code, do the try include("nuclearimaging")
if it finds it, load "Normalized PET" in IntrAnat, and if not load the "input PET".

lot of work ...
if they don't plane to make the nuclear imaging toolbox publicly available, I don't know if it worse it. even if in some Deep Brain Stimulation case, the pathology would benefit from having a partial volume corrected PET, in epilepsy not that much, what we are looking for is quite "diffuse". and for now IntrAnat is almost only used in epilepsy context.

but for others anatomical toolbox, using flair, fgatir etc ...
are we do lot of morphological analysis, it's probably more important to do something that works with and without the toolbox using these filetypes.
pdeman
Posts: 39
Joined: Thu Sep 17, 2015 4:09 pm
Location: moving sometimes

Re: Checking existence of a Format or FileType

Post by pdeman »

and for the transformation file I guess I will have difficulties ...
what we have:

Code: Select all

'PET-<subject>_<acquisition>', SetType( 'Referential of PET' ),
'PET-<subject>_<acquisition>_TO_Talairach-ACPC', SetType( 'Transform PET to Talairach-AC/PC-Anatomist' ),
'PET-<subject>_<acquisition>_TO_Talairach-MNI', SetType( 'Transform PET to Talairach-MNI template-SPM'),
'PET-<subject>_<acquisition>_TO_Scanner_Based', SetType( 'Transformation to Scanner Based Referential' ),
'PET-<subject>_<acquisition>_TO_{modalityTarget}_{acquisitionTarget}', SetType( 'Transform PET to another image' ),
'PET-<subject>_<acquisition>_Scanner_Based', SetType( 'Scanner Based Referential' )
and they do it differently.
I guess this will be a difficulty as well.
pdeman
Posts: 39
Joined: Thu Sep 17, 2015 4:09 pm
Location: moving sometimes

Re: Checking existence of a Format or FileType

Post by pdeman »

I realize that these basic neuroimaging types are used in several independent toolboxes, so I guess in later releases we should probably define most of them in a central place in Axon, not in toolboxes, even when they are not used yet. Either in builtin, or in a separate file at the same location, let's say "neuroimaging" for instance. But for now this is not done this way, so you will have to use the trick above.
I guess a "solution" would be to include in the brainvisa publicly available at least the filetype and hierarchies declared in the independant toolboxes.
these files does not include any "confidential" material I think.
that could help to avoid this kind of problems.
User avatar
riviere
Site Admin
Posts: 1361
Joined: Tue Jan 06, 2004 12:21 pm
Location: CEA NeuroSpin, Saint Aubin, France
Contact:

Re: Checking existence of a Format or FileType

Post by riviere »

Getting the "standard neuroimaging data types" such as PET or FLAIR in a centralized place in axon would be a good start, and we will do so actually. But it doesn't solve all problems. Toolboxes use these types in different ways, probably place files at different locations in different organizations, so I don't know if it would be something good to impose a data organization by providing a builtin hierarchy for PET data and transformations: the way the nuclear imaging toolbox organizes files may not correspond to the needs to Intranat or another toolbox, which would maybe require additional attributes and directory levels... unless all agree on the same organization...
When the base types are defined, a toolbox is free to define sub-types associated with their specific file organization (hierarchy), but then it would not avoid the work of redefining them in each toolbox.
Otherwise it should be OK to release a part of the nuclear imaging toolbox types and files organization, but is it the right thing to do ?
Post Reply