Skip to content
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

Misleading warning emitted when saving movie without file_name to hdf5 (e.g. doing motion correction without saving first) #1429

Open
ethanbb opened this issue Nov 30, 2024 · 1 comment

Comments

@ethanbb
Copy link
Contributor

ethanbb commented Nov 30, 2024

Your setup:

  1. Operating System (Linux, MacOS, Windows): Linux
  2. Hardware type (x86, ARM..) and RAM: x86, 128 GB
  3. Python Version (e.g. 3.9): 3.11
  4. Caiman version (e.g. 1.9.12): 1.11.3
  5. Which demo exhibits the problem (if applicable): N/A
  6. How you installed Caiman (pure conda, conda + compile, colab, ..): conda + compile
  7. Details:

I encountered the "No file saved" warning when trying to do motion correction on just an ndarray (for a test). There is code to save an ndarray or movie to a temporary .hdf5 file first, but it doesn't set the file_name attribute on the movie if it's not already a movie that has one. As a result, saving file_name fails:

try:
dset.attrs["file_name"] = [a.encode('utf8') for a in self.file_name]
except:
logger.warning('No file saved')

...because file_name is [None] and (None).encode('utf8') doesn't work. In practice, I realized since it's just a warning the code will continue and work as expected, but may as well fix it to avoid any doubt.

Suggested fix: change to dset.attrs["file_name"] = [a.encode('utf8') for a in self.file_name if a is not None]
Optional additional fix: in motion_correction.py line 177, set file_name when creating the movie: caiman.movie(fname, file_name=mc_tempfile).save(mc_tempfile) (however this will not overwrite file_name if fname is already a movie)

@pgunn
Copy link
Member

pgunn commented Dec 6, 2024

Longer term we'll probably not want to base filenames on each other as we improve pathing logic and keep runs isolated from each other while saving metadata elsewhere (likely instead just using a static filename), but this seems like a good solution in the middle term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants