-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Prairie View XML Framerate #33
Comments
Hey @jmdelahanty! An example for reference: <?xml version="1.0" encoding="utf-8"?>
<PVScan version="5.6.64.400" date="11/3/2022 11:20:34 AM" notes="">
<PVStateShard>
<PVStateValue key="framePeriod" value="0.032950206" />
</PVStateShard>
</PVScan> This would mean a rate of ~30.35, which is usually higher than what I get when calculating the "true" frame rate from the relative (or absolute) timestamps of the frames. I was wondering whether you made the same conclusion here. |
Hello! I'm so glad you're finding some of this useful! I think a fair bit of it might be lab specific, but I hope there's at least a few parts that are helpful. It's one of my favorite things about OSS! This is indeed what we're finding with versions past 5.5.64.500. I haven't systematically gone through all the recordings we have, but it's a problem. I've notified Bruker about this but thus far the response is that since the relative timestamps are accurate we still have the needed information. This is unfortunate since other processing/best practices relies upon having accurate framerates. I'm not sure if other labs/orgs are aware of it. The frame period/frame rate is liable to change very slightly from recording to recording but appears to be precise within recordings. It's apparently due to "weirdness in how scanning is done over the 8kHz line". There's another repo in this lab's org that goes over things related to Bruker's data/information called bruker_control but I don't know if any of that would be useful to you. If there's other ways I can help let me know! Could also be helpful to check out the nwb_utils.py script that @chrisroat and @RyanLy helped me make. That's meant to grab any metadata fields that were relevant to NWB files and populate them with information. |
It's been discovered through the use of an Oscilloscope as discussed here that the framerates Prairie View reports in its software and, therefore, API is incorrect. This means that any framerate used in Suite2p or SLEAPy faces will be using an incorrect framerate and things may not align correctly when plotting/analyzing data.
Bryan offered some
awk
code for parsing the XML from Prairie View for a given file:I'm not particularly familiar with how exactly this bash script works as I'm very much an
awk
novice. The basic idea I think is:awk
This should be made into a script that can iterate over different directories either in Python or MATLAB probably since not too many people in lab are familiar with using
awk
other than Bryan I think...Given that we can't trust that Bruker's software notes the correct framerate in their software/API and additionally since it's not known how long this incorrect value has been given from their software, we should go probably do the following for all our 2-photon recordings from the older Ultima Investigator:
Verify Framerates in Environment against Framerates from Timestamps
framerate
reported in the environment file matches the true framerate from the relative framerate timestampsThe text was updated successfully, but these errors were encountered: