Depth of grid space

[CodyCBakerPhD]

The zScan.json file in the raw pumprobe folder has the following structure (aside from the waveform)

 'latencyShiftPermutation': 258,
 'V/um': 0.125,
 'waveType': 'triangle',
 'etlCalibrationMindpt': -1,
 'etlCalibrationMaxdpt': 1,
 'piezoEtlClockLock': False,
 'volumeHeight': 30,
 'volumeHeightUnits': 'um',
 'etl dpt/um': 0.05,
 'etlVMin': 0,
 'etlVMax': 5

Should the grid spacing information for the z axis be pulled from the V/um field or the volumeHeight?

From the parent library pumpprobe uses for I/O, it seems as if the volumeHeight is not used: https://github.com/leiferlab/wormdatamodel/blob/2ab956199e3931de41a190d2b9985e961df3810c/wormdatamodel/data/recording.py#L615

[CodyCBakerPhD]

@emosb In NWB, we characterize the ImagingPlane using a grid_spacing that in the volumetric case describes the 'distance' of each dimension of a voxel in micrometers - is the volumeHeight field valid for the depth axis? I didn't see any usage of the field in the wormdatamodel

[emosb]

To my understanding looking through wormdatamodel, the volume height is determined by the Voltage stored in the second column of other-frameSynchronous.txt (which I believe is actually the voltage supplied to one of the Electrically Tunable Lenses and not the Piezo - I will check on this!). The voltage stored here is then multiplied by 1/0.125 (0.125 = the V/um) and by 1/0.42 (0.42 = a hardcoded um/pixel) to get a z value in pixels. I am not sure whether the choice to use pixels as the unit is necessary in later steps of the pipeline - I can get back to you on that.

If you want grid spacing in um, I believe based on the wormdatamodel code it is more accurate to use the V/um field. Checking with the first full volume in the hermaphrodite dataset, converting V to um this way gives a full volume height of 29.93 um. The second is 29.97 um. I think 30 um is generally what the volume height is set to but there is some error in the actual volume acquisition.

[CodyCBakerPhD]

Sounds great, I did not think to check that field on the other-frameSynchronous.txt file

I will use that plus V/um value in the configuration file to scale them into physical units