naf issueshttps://vcs.ynic.york.ac.uk/naf/naf/-/issues2018-02-21T19:29:24Zhttps://vcs.ynic.york.ac.uk/naf/naf/-/issues/1Window information is incorrect in reports2018-02-21T19:29:24ZMark HymersWindow information is incorrect in reportsThe information displayed in NAF reports about Time Windows is incorrect if a pre-trigger has been used.
This is because the underlying TimeWindow object is offset relative to the pre-trigger. Thinking about this, it is obvious that thi...The information displayed in NAF reports about Time Windows is incorrect if a pre-trigger has been used.
This is because the underlying TimeWindow object is offset relative to the pre-trigger. Thinking about this, it is obvious that this must be the case to avoid leaking information to the rest of the processing chain.
The issue is probably that we use the TimeWindow class for two things:
1. Defining 'Abstract' study time windows - i.e. I want active to be from 100ms to 400ms in my epoch
2. 'Concrete' study time windows - I now have a dataset in which I will be extracting an epoch of data and need to be able to calculate which points within that epoch are referred to by this window.
There are a couple of possible ways to deal with this. The easiest would be for TimeWindow to have an (optional) display_offset value which is correctly initialised when it is returned from the Study object - we would then add a get_display_ms() routine which would be used. [Actually, thinking about it, does anything ever need the time window in ms which is *not* offset?]
Another way would be for us to split TimeWindow into two classes as mentioned above - the 'abstract' TimeWindow class would not have the above ability but the 'concrete' one would. If we were to do this, we would have to use TimeWindow as the 'concrete' one and rename the 'abstract' one. This is because all existing HDF5 files have the TimeWindow baked into them and they should all be 'concrete' representations.
I'll try and work up a patch for this at some point, but if anyone wants to help out, that would be great Needless to say, test cases will need to be added for all of this to avoid making a nasty mistake somewhere...https://vcs.ynic.york.ac.uk/naf/naf/-/issues/5MEGHDF5: Epoch rejection2017-07-16T15:28:25ZMark HymersMEGHDF5: Epoch rejectionFix epoch rejection script to work with MEGHDF5 and CTF readers as well as BTI readerFix epoch rejection script to work with MEGHDF5 and CTF readers as well as BTI readerMark HymersMark Hymershttps://vcs.ynic.york.ac.uk/naf/naf/-/issues/6get_channel_coords routine2017-07-16T15:29:47ZMark Hymersget_channel_coords routineImplement get_channel_coords routine in abstractdata:AbstractData
Should have the API: get_channel_coords(chans, transform, space)
and then call get_channel_geometry internally, then transform the data and return it.
This would simplif...Implement get_channel_coords routine in abstractdata:AbstractData
Should have the API: get_channel_coords(chans, transform, space)
and then call get_channel_geometry internally, then transform the data and return it.
This would simplify places where channel information is needed in a particular co-ordinate space (see all of the forward model generator classes)Mark HymersMark Hymershttps://vcs.ynic.york.ac.uk/naf/naf/-/issues/7Implement COH registration routine2017-07-16T15:32:46ZMark HymersImplement COH registration routineWe need to implement a routine which can use coil inductance calculations to take COH energisation data and fit the channel positions into the Subject Co-ordinate Space.
This involves:
* coil inductance calculations (@sam has a routine...We need to implement a routine which can use coil inductance calculations to take COH energisation data and fit the channel positions into the Subject Co-ordinate Space.
This involves:
* coil inductance calculations (@sam has a routine for this already)
* calculating an initial guess (weeder style)
* a fitting algorithm
* routines to wrap the above.https://vcs.ynic.york.ac.uk/naf/naf/-/issues/8Pre/Post scan movement graphs are BTI specific2017-07-16T15:32:46ZMark HymersPre/Post scan movement graphs are BTI specificThe code which plots the pre/post scan movement graphs in the reports is specific to the BTIMegReader class
This needs to be more general for CTF / MEGHDF5 data - for some data types this might mean calculating this ourselves from the r...The code which plots the pre/post scan movement graphs in the reports is specific to the BTIMegReader class
This needs to be more general for CTF / MEGHDF5 data - for some data types this might mean calculating this ourselves from the raw data. See #7 for a ticket to implement that functionality.https://vcs.ynic.york.ac.uk/naf/naf/-/issues/13Migrate to nibabel2017-07-27T13:30:26ZMark HymersMigrate to nibabelIn many places, we are still using python-nifti
This has been undeveloped for years - nibabel is the replacement.
Changing over is slightly tricky as the API has changed somewhat. For instance, wherever we reverse the order of the dim...In many places, we are still using python-nifti
This has been undeveloped for years - nibabel is the replacement.
Changing over is slightly tricky as the API has changed somewhat. For instance, wherever we reverse the order of the dimensions in data because that's how pynifti returned it, we need to stop doing that when we move to nibabel.
This needs careful regression testing adding and doing.