Control what appears in dicominfo

[crcox]

Summary

This is just a question. I am exploring many acquisition protocols at the moment. Some of the information distinguishing those protocols can be found within the DICOM header, but is not reported in dicominfo.tsv. Is there an easy/intended way for the content of dicominfo to be controlled? [edit] What I am really interested in is the information in sessinfo that can be accessed in the heuristic.py script, which appears to mirror the content of dicominfo.

Platform details:

Choose one:

• Local environment

• Container
  docker.io/nipy/heudiconv latest afdef7270c0e

• Heudiconv version:

0.9.0

[yarikoptic]

Unfortunately not and we have related pr to store path to a sample dicom file #333

I wonder if we should just allow heuristic to specify a list of fields to be extracted which we would just store somehow (allowing later for expansion of our record) in the tsv - we would just need to take care about possible tabs in the values to but interfere

[satra]

i guess this is more of a design issue. since the infoonly option does not care about the heuristic file, adding options should be outside of the heuristic i think. so perhaps an additional option to heudiconv. indeed #333 was created primarily to allow the heuristic to extract any info from the dicom file without having to specify the fields a priori.

i think there is also a related issue of what goes into the bids sidecar file, which at present limited to the fields that are harmonized by bids (i.e. vendor neutral). in the past we also did this through a nifti extension that stored the dicom info. however, this incurs the potential for private information leakage, and so has to be added with care.

i feel these considerations are all all related and would be nice to come up with a clean set of options and flags. i think the non-harmonized info can be quite useful for future interpretation of files outside of the lab which produced them, which at this point are purely interpreted through the bids metadata. so it's not just storing a pointer to dicom metadata in the source tree, but allowing someway of distributing it, whether in json or in nifti.

[crcox]

@satra At the risk of wading out of my depth: I agree with you that this might best be implemented as an option to heudiconv, rather than at the point of the heuristic script. Like a DicomHeaderExtras option, or something, that would accept a list of inputs from the command line. I imagine that would be sufficient for most use cases. In my specific case, there is just one additional DICOM header variable that I wish heudiconv could see and that I could reference in the context of the heuristic.

[yarikoptic]

Well, I think this is just a manifestation of multiple possible workflows on how heudiconv could be used.

In my use-cases they are heavily "heuristic-driven" and do not rely on manual tune up of all the .edit.tsv. So if heuristic needs extra information from DICOMs it is only reasonable to have that heuristic to specify what extra fields (and possibly with some harmonization across scanners etc) to extract so they could be used later.

NB I actually would like also to have heuristic be able to specify that it is intended to produce BIDS datasets, which now must be an extra command line option --bids.

Having those extra DICOM fields specified in command line, but used by a specific heuristic breaks them apart, and would require user to remember on extra command line options to use (like now with --bids and e.g. reproin heuristic). So if I were to implement it (do not have immediate use case ATM and thus direct need to develop), I would

• add support for heuristic to provide def extra_seqinfo(mw, series_files, series_id) to be called probably from group_dicoms_into_seqinfos after create_seqinfo (or within that one since SeqInfo is a named tuple and we would need to expand its signature "dynamically") to populate with any extra field(s) needed by heuristic. Warning might be issued if returned fields conflict (and differ in value) from what heudiconv provides in its "base" SeqInfo structure
• document that such a function should be defined only in heuristics which do not rely on positional indexing of the fields in seqinfo, and use named fields within seqinfo. With this, even after upgrade of heudiconv were extra fields added to the "base" SeqInfo, heuristic would remain working.

I of cause would not mind if someone proposes a command line option which would provide extra fields extraction from DICOMs. Those should then be applied to enhance SeqInfo after possibly already added extra fields by heuristic. Not sure how resilient it would be across heudiconv version changes which would add extra fields in base SeqInfo in this case though.

[brussj]

Related to this topic, I can give an example where adjusting dicominfo would be helpful:

We have a GE Discovery MR750W scanner and data from two different software versions, DV25 and DV26. The scanner was later upgraded to a Signa Premiere, software version RX28. For our T1 BRAVO sequences, the data gets stored in both the original/unfiltered form as well as the processed/PURE (motion-corrected) form. "sequence_name" has these both stored as "BRAVO." There is a DICOM tag "0043,102d" that stores information on the original/processed type as follows:

model,softwareVersion,type,dcmTag

Discovery MR750W,DV25,orig,"w"
Discovery MR750W,DV25,PURE,"P+w"
Discovery MR750W,DV26,orig,no tag
Discovery MR750W,DV26,PURE,"wp+"
Signa Premier,RX28,orig,no tag
Signa Premier,RX28,PURE,"wp+"

As you can see, depending on the model and software version, the DICOM tag may not exist. When it is there, "wp+" and "P+w" would be the tags denoting the PURE form. To make things more frustrating, the "series_description" isn't very consistent across the models and software versions.

The ability to add in "0043,102d" and possibly a way to name that field in dicominfo (there is no field name in the DICOM tag) would be immensely helpful.

[tjhendrickson]

Wondering if there was ever a resolution to this?

[yarikoptic]

If I re-understood the desire correctly here, I think we got

• Add support for a custom seqinfo to extract from DICOMs any additional metadata desired for a heuristic #581
  released in v1.1.0 (Wed Feb 28 2024) . Try it out?

• doc: https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/convertall_custom.py#L16

• example: https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/convertall_custom.py#L16

• PR to improve doc with the example URL etc: Improve formatting in custom_seqinfo doc + provide url to an example #815