[ ] handle up to five or more channels (though most will be 2 or 3 channels)
[ ] handle 2048x2048x16 image (smaller i.e. 512x512 or 256x512 are more common)
[ ] Z is typically 150 to 300 though could be upwards of 1600+
[ ] sample is either galvo scanned or piezo scanned; piezo scanned requires deskewing - software needs to tell the difference
[ ] have no real upper limit on number of time points though current typical is 600 to 1000
[ ] number of stacks imaged listed metadata can be wrong (and final stack incomplete) if the user stops acquisition early
it would be very useful if the software can tell the difference i.e. reconcile the difference between number of stacks and the metadata, possibly erase the partial stack and correct the metadata
[ ] allow user to deskew only, decon only or deskew/decon
[ ] default to decon with experimental PSFs but allow for alternate PSFs
[ ] extract pertinent data from labview metadata, use the data for processing obviously and also populate a companion data file that carries with the experiment
[ ] cope with data sets if the channels are created on two separate cameras
Notes:
it is preferable that the deskew/decon metadata is digestible by Imaris (the main image analysis platform available to users) so that users don't have to manually change the stack properties
PSFs are 64x64x51 XYZ pixels, with a Z voxel of 0.100 um) if galvo scanned
sample scanned PSFs are 64x64 XY pixels and the Z pixel can be variable as can the Z voxel - data will be in labview metadata
typically the galvo scanned PSF will be used for deconvolution
sample XYZ is not camera XYZ only Y is common
camera XY is 0.104 micron per pixel though this could change in the future
camera Z is either the galvo scanned step increment or (sample scanned increment)(cosine(58.2 degrees))
stack labview metadata contains the information needed to determine proper deskew sample increment and between galvo and piezo scan
data files and PSF files are located in specific folders (though some older experiments will vary as the overall system was fleshed out during use)
available matlab code is a stub
available cuda app is compiled for windows; janelia has been asked for the source code
Keith's java code respects the labview metadata and creates a post process companion file. The matlab does not. Haven't tried the cuda but I understand it ignores metadata as well.
A proper pipeline would:
[ ] stream a copy the data to an M3 workspace
[ ] deskew would occur automatically using the labview metadata
[ ] decon if the user asks for it and allow for setting decon variables
[ ] send an example deskewed single data stack back to the user for pre-visualisation if the user requires
only useful if the process is very fast i.e. less than a minute
[ ] after processing, move the data over to store.monash for archival
In practice I don't think this will be useful to send the user a decon pre-vis as decon takes too long and the cells will be changing/dying but if you can create a super fast decon go for it.
[ ] It would also be useful to rotate the sample within the image volume so that the plane of the sample is parallel with the plane of the image volume i.e not at 31.8 degrees from the plane. But only if you store the recalculated rotated sample XYZ voxels sizes in the metadata file so the users know and can enter the values into any imaging software.
From David:
Notes:
A proper pipeline would:
In practice I don't think this will be useful to send the user a decon pre-vis as decon takes too long and the cells will be changing/dying but if you can create a super fast decon go for it.