Back to the main page.
Bug 1095 - negative trialpadding in ft_artifact_zvalue
| Status | CLOSED FIXED |
| Reported | 2011-11-01 12:02:00 +0100 |
| Modified | 2019-08-10 11:56:51 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | All |
| Operating System: | All |
| Importance: | P4 enhancement |
| Assigned to: | Stephen Whitmarsh |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Stephen Whitmarsh - 2011-11-01 12:02:18 +0100
ft_artifact_zvalue has the possiblity for specifying trialpadding. This helps prevent edgeartifacts (of the z-value based on edges, especially when using filter options), but only when reading from disc. When you have data in memory already, after preprocessing, this does not work. Solution might be simple: provide possiblity for 'negative trialpadding', i.e. only do artifact rejection on smaller window (e.g. starting 100 ms later, and ending 100 ms earlier). What do you think? (p.s. ofcourse working with partial artifact rejection is a possible workaround, but only in some cases). cheers, Stephen
Boris Reuderink - 2011-11-17 10:46:50 +0100
Changed the status of bugs without a specific owner to UNCONFIRMED. I'll try to replicate these bugs (potentially involving the submitter), and change confirmed bugs to NEW. Boris
Boris Reuderink - 2011-11-17 14:10:47 +0100
What should we do? Discuss in meeting? On mailing list? Here?
Boris Reuderink - 2011-11-28 16:07:37 +0100
Bump.
Boris Reuderink - 2012-01-03 14:32:04 +0100
Bump.
Stephen Whitmarsh - 2012-02-13 18:14:18 +0100
I now tried to fix the problem with a workaround that ended up driving into another dead end bug (will post in another) Taking another look at this suggestion for improvement I think the best way would actually be to introduce a toi field. That should also we relatively easy for someone who knows the code of ft_artifact_zvalue - which seems it could use a little cleaning up anyhow. Anyone wants me to look over their shoulder, or to buy them chocolates? And yes that is a bribe :-) ~S~
Jan-Mathijs Schoffelen - 2012-02-13 19:30:39 +0100
I strongly oppose against 'cleaning up' ft_artifact_zvalue' because it has been reimplemented about five times by now (most of the times by me), and I am pretty happy with the result... I don't understand what is meant with the 'toi'. If it is the purpose to disregard 'artifacts' close to the edge of the trial (with data in memory), actual specifying a negatively valued trlpadding makes sense, and could be implemented without too much hassle. Of course the default would still remain 0.
Jan-Mathijs Schoffelen - 2012-02-23 12:11:47 +0100
FIXME: we should also think about the correct begin and endpoints of the detected artifacts in the context of negative trial-padding. When artpadding > 0 the begin/end points could fall within the padded part of the data. This is not the case at present
Stephen Whitmarsh - 2012-05-31 10:23:37 +0200
this wsa done a while ago. note its use is documented on the wiki