Option to output parent/child aligned single cell profiles instead of image/object number

[gwaybio]

Currently cytominer_transport/_generator.py combines objects based on "ImageNumber" and "ObjectNumber".

Instead, we should consider combining objects by their appropriate "Parent_{compartment}" and "Child_{compartment}".

Pros

• The profilers are increasingly using single cells as the analytical unit, instead of aggregated profiles
• if cytominer_transport could output analysis ready single cell data, it will save profilers loads of time (it'll basically obviate a pycytominer step of taking in parquet files, rearranging rows based on parent/child columns and then outputting a new file

Cons

• If some experiments have a high discrepancy between objects (e.g. 20,000 measurements in one object aligned to a total of 500 measurements in a separate object) will cause a much larger file size
  • Although I am not entirely sure this is not happening even now with pandas.concat(axis=1)

cytominer-transport/src/cytominer_transport/_generator.py

Lines 64 to 66 in 056ced3

	concatenated_object_records = pandas.concat(
	[concatenated_object_records, object_records], axis=1
	)

Notes

• I think this functionality is independent of Output aggregated profiles in additional to single cell profiles #7 since the fundamental analytical units differ.
• However, If we do implement this parent/child merge, before a potential aggregation (as described in Output aggregated profiles in additional to single cell profiles #7) the results will be different; depending of course on how many times (and the variance of) individual objects are duplicated upon the merge

[gwaybio]

Below is how pycytominer currently addresses this:

https://github.com/cytomining/pycytominer/blob/838ac2eee8bee09b50a1ec8077201c01f7882c69/pycytominer/cyto_utils/single_cell_ingest_utils.py#L5-L23

[bethac07]

A complication here is that, in the case of multiple objects, there can be many relationship types-

• entirely uncorrelated (A and B are identified separately and have no parent/child relationship at all)
• one-or-zero-to-any (large parent objects with zero-to-many smaller child objects in it; some small objects may have no parent)
• one-to-zero-or-one (an original parent object filtered into 0-or-1 child objects, like Cells into GFPPositiveCells)
• one-to-one (Nuclei into Cells, then Nuclei and Cells into Cytoplasms, guaranteed that all objects are one-to-one; this is the condition that what you linked supports)

I think the logic to detect and/or support all of them might be rough; we should consider how to handle each of them, and whether or not the user needs to pass a flag or a configuration or something to make it easier to decide.