Appending reconstructed channels gives zero arrays

[Soorya19Pradeep]

Summary
RecOrder reconstruction of channels and appending it back to the same zarr as a new channel gives zero arrays. This method combines steps of iohub MM to zarr conversion and reconstruction, both producing arrays of same size.

Code and data for reproduction
I tried both
recorder reconstruct $INPUT_PATHS -c ./phase.yaml -o $OUTPUT_PATH
as well as

recorder compute-tf -i $INPUT_PATHS -c ./phase.yaml -o phase_tf.zarr/
recorder apply-inv-tf -i $INPUT_PATHS -t phase_tf.zarr -c ./phase.yaml -o $OUTPUT_PATH

This was tried on /hpc/projects/group.leonetti/opencell-infection-microscopy/TICM0051-1/TICM0051-1_raw.zarr. The reconstructed BF channel MultiCam_GFP_mCherry_BF_narrow-Zyla was appended as a new channel Phase3D in this zarr.

Expected behavior
The reconstructed data appended to the iohub converted zarr should be phase values, not zeros.

Environment:
Operating system: Linux, HPC
Python version: Python 3.10
Python environment (command line, IDE, Jupyter notebook, etc): command line

[ziw-liu]

The 5-th channel is indeed not written:

/hpc/projects/group.leonetti/opencell-infection-microscopy/TICM0051-1/TICM0051-1_raw.zarr/B/3/8 du -ah -d 2 0
4.0K    0/.zarray
42M     0/0/3
33M     0/0/0
268K    0/0/4
26M     0/0/2
32M     0/0/1
131M    0/0
131M    0

I noticed that the array has the data type of u16, which is incompatible with phase:

    "dtype": "<u2",

We may need to revise the data organization to not only create a new store when the shape changes, but also when the data type changes (e.g. reconstruction).

@Soorya19Pradeep did recOrder throw any error during reconstruction?

[ziw-liu]

We may need to revise the data organization to not only create a new store when the shape changes, but also when the data type changes (e.g. reconstruction).

Alternatively, we can cast the raw data into float32 (where the full range of uint16 can be preserved). During storage and I/O this will be a small hit thanks to compression, but at runtime this will incur 2x memory usage. Also this seems less intuitive to me.

[Soorya19Pradeep]

The 5-th channel is indeed not written:

/hpc/projects/group.leonetti/opencell-infection-microscopy/TICM0051-1/TICM0051-1_raw.zarr/B/3/8 du -ah -d 2 0
4.0K    0/.zarray
42M     0/0/3
33M     0/0/0
268K    0/0/4
26M     0/0/2
32M     0/0/1
131M    0/0
131M    0

I noticed that the array has the data type of u16, which is incompatible with phase:

    "dtype": "<u2",

We may need to revise the data organization to not only create a new store when the shape changes, but also when the data type changes (e.g. reconstruction).

@Soorya19Pradeep did recOrder throw any error during reconstruction?

No @ziw-liu , recOrder did not through any error.

[Soorya19Pradeep]

@ziw-liu , thanks for the input. I guess I will go with two zarr stores if that is more efficient.

[talonchandler]

@Soorya19Pradeep I agree that you should proceed with two zarr stores.

If we decide that this issue is a priority, we'll need to decide:

• how to handle datatypes (thanks for flagging @ziw-liu). Our inputs are commonly uint16 and our outputs are typically float32.
• how to handle non-matching shapes (e.g. 2D phase). Probably just error.
• how to handle multiple reconstructions?