How does CaImAn handle 8-bit vs 12-bit color depth?

[kushalbakshi]

Hello all,

I'm helping @andrestrocyte and @MathiasMahn set up a miniscope processing routine that uses CNMF-E, and we would like to know if CaImAn is handling 8-bit vs 12-bit color depth differently? The Inscopix miniscope generates images with 12-bit depth whereas the UCLA miniscope generates images with 8-bit color depth. Are these treated differently when loaded into CaImAn or is there a parameter we need to set? Are there any caveats that we should be aware of for the higher or lower bit-depth images?

Thank you!

[pgunn]

Hello,
What format are the movies in? I believe some of our example movies are 16-bit; I don't think we have 12-bit examples but I'm also not aware of data formats that explicitly separately support 12-bit color.

[kushalbakshi]

Hello, What format are the movies in? I believe some of our example movies are 16-bit; I don't think we have 12-bit examples but I'm also not aware of data formats that explicitly separately support 12-bit color.

Hi @pgunn, I know the UCLA miniscope movies are .avi format. Let me check with @MathiasMahn about the format of the Inscopix movies and get back to you. We're also looking into exporting the raw movies from Inscopix to .avi but it will retain the 12-bit color even after the export.

[MathiasMahn]

Hi @pgunn,
We are performing miniscope calcium imaging using UCLA as well as Inscopix miniscopes, both recording in greyscale. We are working with @kushalbakshi to analyse the recordings using the CaImAn package integrated into a Datajoint workflow.
The UCLA data is saved as uint8 avi. The inscopix data is recorded in their proprietary format (.isxd), which we can load using the inscopix isx python package. Here we see that the max. value is 2^12.

My question is how to best handle these two file formats for use with the CaImAn package.
What we have considered so far is:
Option 1: Transform Inscopix movies to 8-bit avi files and create same avi as for UCLA miniscope recordings -> How detrimental is the resulting information loss? Especially if we scale the min max values of the movie to 8 bit?
Option 2: Transform Inscopix movies to 16-bit avi files -> No information loss, but resulting in double the file size. We could delete these files after motion correction was successful, to minimize data duplication.
Option 3: Integrate the Inscopix reader directly before the NoRMCorre motion correction instead of passing the path to a file. But from looking at caiman/motion_correction.py, this seems non-trivial to implement.

Happy to hear your thoughts.

Thanks!

[pgunn]

Unless you're pressed for storage, the second option seems fairly low-fuss and should give good results.

[kushalkolar]

Everything becomes f32 or f64 (forgot which) anyways once you do motion correction

[kushalkolar]

Everything becomes f32 or f64 (forgot which) anyways once you do motion correction

Also not sure what you mean "color depth", do you mean multiple grayscale channels?

[kushalbakshi]

Everything becomes f32 or f64 (forgot which) anyways once you do motion correction

Also not sure what you mean "color depth", do you mean multiple grayscale channels?

Thanks for getting back to me on this @kushalkolar.
That's a good point - since it's f32/64, the results for segmentation shouldn't be affected by this difference.

And by color depth, I meant 8-bit vs 12-bit encoding for each channel. There are no differences in how many total channels there are between the two different recordings.