Closed neuromusic closed 4 years ago
I agree, and I would prefer to just have img_mask and do away with pixel_mask entirely. If we really care about space efficiency, we can use gzip and the size should be about the same without much performance overhead.
From an API perspective, I think it is fine to allow both ways. I.e., we could store the data in NWB:N always as either an img_mask or pixel mask but on the API side allow the user to get the data either way. I.e., removing either img_mask or pixel_mask from the schema doesn't mean you couldn't have a convenience function to translate one into the other for users.
With regard to storage. If the masks are sparse (i.e., have less than say 30% of pixel selected per image) then having a pix_mask would likely be more efficient. However, if the masks are dense, than the img_mask approach will be better. From a storage perspective, it is correct that you could compress the img_masks and probably get reasonable data sizes. The main problem I think here in terms of performance is more on the read/write performance and usage of memory when you need to have the data in memory.
Long story short.
For our use cases each ROI will generally be a very small fraction of the overall reference image.
This issue has been resolved.
🎉
the following attributes are required to define an ROI
img_mask
is redundant withpix_mask
+pix_mask_weight
it should be required to define
img_mask
ORpix_mask
+pix_mask_weight