Possible wrong channel order when loading an imro file for NP2

[MarineChap]

Hello, We detected a problem with loading the channelmap recently. (Note: we are still on the old API) Lies want to see in open ephys viewer the signal ordered by depth. I saw this feature will be develop in the lfpviewer but anyway it won't be ready for the oe version we are using. (old api) So, the easiest way to solve the problem I though was to order the channel by depth from the start inside the imro. For example I have my usual channelmap and then I do that

def order_imro(input_path, output_path):
    probe_non_order = pb.read_imro(input_path)
    probe_ordered  = probe_non_order.to_dataframe(complete=True).sort_values("y").reset_index(drop=True)
    probe_ordered.loc[:,"device_channel_indices"] = list(range(len(probe_ordered["device_channel_indices"])))
    probe_ordered = probe_non_order.copy().from_dataframe(df=probe_ordered)
    probe_ordered.annotations = probe_non_order.annotations
    pb.write_imro(output_path, probe_ordered)

That's work with probeinterface. See the image (ordered on the left / non-ordered on the right. But when I load in open-ephys the channelmap, no matter which one ordered or non--ordered, it always re-shuffle everything to give me the non-ordered. So I don't understand what is happening here. Is it a bug in open ephys ? Is it me none understanding something on the imro format ? I give you in attached the two imro file too.

Thanks. Have a good day.

fourth_density_shank_0_original.txt fourth_density_shank_0_ordered.txt

[jsiegle]

The IMRO format can only be used to specify the mapping between channels and electrodes; the channel ordering within Open Ephys will always be the same, regardless of the order of the entries in the IMRO file.

To display the channels in order in v0.5.x, you could try copying the changes from LfpDisplay::rebuildDrawableChannelsList() from 0.6.x. But that might end up being a bit complicated, as the way channel location metadata is handled has changed significantly (for the better, we think).

If there are specific plugins that are blocking you from switching to v0.6.x (e.g. Falcon Output), we'd be happy to help with the conversion (this is next on our to-do list anyway).

[MarineChap]

Hello, I think that is the point that i am missing... If I understand correctly that means you are ignoring the channel id marked in the imro file (for NP2.0 format) to put your own based on the channel ordering given by the hardware ? Why not reordering to be consistent with the imro given in input ?

For falcon-output, it is indeed why we are staying in the previous version. If it is the next to update, super great because i really don't have the time to work on it. What is the timeline ? Because me, I will have finish my contract in nerf in 1 month and half.

Thank you

[jsiegle]

I think the problem is arising from the fact that fourth_density_shank_0_ordered.txt is not a valid configuration file.

Each entry in the NP2 4-shank IMRO table must contain 5 values:

• Channel ID
• Shank ID
• Bank ID
• Reference ID index
• Electrode ID (range [0,1279] on each shank)

In this case, the shank ID and reference ID index are always 0, so we can ignore those.

For a given Channel ID, there is only one possible Electrode ID for each Bank ID. For example, for channel 1, if Bank ID = 1 (Bank B), then the Electrode ID must be 385. In the "ordered" IMRO table, the Electrode ID is set to 4, which is not possible given the physical connections on the probe.

Because of this redundancy, the Neuropixels plugin ignores the Electrode ID and only uses the Bank ID and Shank ID to select electrodes. Since these values are the same between the two files, the two configurations are identical.

[jsiegle]

Re: Falcon Output, converting this to the v0.6 API is next on our to-do list, so we should have that ready soon. We plan to make changes similar to those for the ZMQ Interface (e.g. adding a channel selector).