Conversation
72c4701 to
71ad5a7
Compare
d7aa4dd to
b656479
Compare
|
I didn't review any of the changes and don't know if there's any side effects to be expected; but purely from a user's POV, I'd say we should definitely try to support this |
sappelhoff
left a comment
There was a problem hiding this comment.
I also think we should support this. Potential issues could arise from concatenating Raw types that support different attributes. For example, the BrainVision Raw supports impedances, but other Raws might not.
|
At a bare minimum we would have to ensure all data are preloaded. And as @sappelhoff points out to keep things simple the resulting class should probably be RawArray since IIRC it doesn't have any extra attributes like impedance and such. (We could later maybe think about how to combine/keep them but I'd rather instead move toward removing them entirely.) |
aeb72bd to
7fc7634
Compare
Co-authored-by: Copilot <copilot@github.com>
|
@larsoner I implemented your suggestions, I think this should be ready for review now. |
| for r in raws: | ||
| if not r.preload: | ||
| r.load_data() |
There was a problem hiding this comment.
I'm a bit surprised you need this. It seems like the logic in raws[0].append(raws[1:], preload) can/should be smart enough to handle this case. Did you try to make this work?
In other words, I would expect something of the form:
if mixed_types:
raws = list(raws) # local copy of list
raws[0] = RawArray(raws[0]._data, raws[0].info, first_samp=raws[0].first_samp)
preload = True
raws[0].append(raws[1:], preload)
after the events code to be potentially much less memory intensive (by a factor approaching 2), and also fewer lines and easier to follow here
There was a problem hiding this comment.
Hmm, you may be right. I pushed a fix, but I think I still have to preload raws[0] in order to use raws[0]._data, right? Also, I think we need to copy the annotations.
There was a problem hiding this comment.
Yeah you're right, you'd either need to preload that one or use .get_data. And yes probably annotations too
Co-authored-by: Eric Larson <larson.eric.d@gmail.com>
Co-authored-by: Copilot <copilot@github.com>
|
I mean, I'm starting to doubt if this is really worth it and if people should just do the conversion manually... WDYT? |
|
Well there are some slightly tricky bits that people can silently get wrong, like the |
|
OK, I think I implemented all of your suggestions. |
larsoner
left a comment
There was a problem hiding this comment.
LGTM +1 for merge once CIs come back green!
As reported in this forum post,
mne.concatenate_raws()only works if all objects share the exact same type. In particular, this means that it is not possible to concatenateRaw(an alias forRawFIF) andRawArrayobjects, and other types likeRawEDF,RawEEGLAB, etc. do not work either. However, since all concrete types inherit fromBaseRaw, I think we could relax the compatibility check accordingly.The following example fails on
main, but works on this branch: