AVI movie data altered after resaving file with movie.save

[rpfisher9]

Hi!
When analyzing our .avi movie files from 1p calcium imaging in CaImAn (version 1.9.15), we noticed videos resaved as a new file with movie.save have a different 3D movie array than the original avi file (see code screenshot below). There were no other changes made to the videos other than loading and taking the average. Has anyone else noticed modified data from videos after saving as a new file or know why this may be happening?

[EricThomson]

I would inspect the movie and make sure it still looks reasonable.

The load function converts to float, and also does an rgb2grey operation on it that can also change the absolute values (this latter operation shouldn't change the relative values if your original is grayscale). We change the data type because there is later lots of floating point arithmetic done on the arrays in the movie.

[rpfisher9]

Hi,
Thank you for the quick response! Our input AVI (shape [1000,608,608]) files are in greyscale and the videos still look reasonable. However, the change in the movie values does not appear to be in load. Below is a graph of a column from a Miniscope frame graph of our original AVI file (in red) and the same column of data from a video that has been saved and reloaded (in blue). Both were loaded in the same manner, so I dont think specifics of the load method explains why the video that was saved and opened has movie values that are so much higher. The graph also appears to artificially cut off at 255, causing the shape of the blue resaved movie to distort.

[rpfisher9]

Hi, following up with some more information in case it helps!
For the above graph, Ive attached reference images with an example column of data shown by the white rectangle. Visually, it is apparent that the frame from the original movie is quite different from the resaved. Shifts in the data's absolute brightness values are not a huge concern, but if the data is being clipped (like it appears to be in the blue trace) would be a problem.

[rpfisher9]

Additionally, Below is a graph of an original (red) and resaved (blue) video from a test recording that had the miniscope recording with no GRIN lens or test subject. The only code run on these videos is load and save (with their default settings), like above. Any thoughts you have would be appreciated!

[EricThomson]

This is strange. What operating system are you in?

If not Windows, if it isn't too much trouble, could you share a small movie (e.g., a couple of hundred frames) and small self-contained code file that you used to recreate these issues?

[EricThomson]

Thanks! I should be able to look at this later this week.

[rpfisher9]

Hi! Just checking in to see if you have any thoughts on what may be going on here. Thank you in advance

[EricThomson]

Sorry I am at a conference -- I will check this out soon!

[EricThomson]

Ok I tried to reproduce and found a bug in Windows save for avi 😭 So I'll need to work on that.

It looks like the default for avi, though, looking on the code is to save with lots of scaling operations that makes it better for viewing more than for processing. If you want to stop that and keep things the same (again, without actually testing it), try setting the q_min and q_max arguments to None, and it will turn this off. Then it should give the same outputs as inputs -- if you don't do that it will try to scale the input to the full dynamic range, which is what we are seeing in your example so it looks nicer for presentations etc.

This is because saving avi isn't really ever used on the back end for processing in caiman it is looked at as something you might want to do to save for a presentation, so things are scaled to look nice.

If your pipeline relies on saving using caiman's save(), I would consider saving to a different format than avi because we have been uncovering issues lately with avi and it is not one of our favorite or most heavily vetted formats. 😄 So if you are already going to resave your data anyway, I'd consider tiff, hdf5.

[rpfisher9]

Hi! Yes it appears that was the default that was changing our movie data, thank you for the help! The pipeline does not require cm.save, I was attempting to flip an avi video because the miniscope was accidentally placed in upside down during a recording and I am hoping to avoid having to rerecord that experiment.