Add QPI-related features to dclab features

[PinkShnack]

We should add several new features that can come from holograms acquired via the Quantitative Phase imaging (QPI) experiments.

Possible features and their types:

Feature	dclab name	dclab type	feature dtype	description
Hologram image	qpi_oah	non-scalar	uint8	Off axis hologram image
Hologram image bg	qpi_oah_bg	non-scalar	uint8	Off axis hologram image background
Phase image	qpi_pha	non-scalar	float64	Phase image calculated from hologram
Amp image	qpi_amp	non-scalar	float64	Amplitude image calculated from hologram
Dry mass	qpi_dm	scalar	float	Dry mass of the event calculated from the phase image
Refractive index	qpi_ri	scalar	float	refractive index of the event calculated from the phase
Integrated Phase	qpi_pha_int	scalar	float	integrated phase
DM and RI std	eg. qpi_dm_std	scalar	float	Stanard deviation of ri and dm

other todos:

• [ ] Add the specific refractive increments, perhaps as discussed here: https://github.com/DC-analysis/dclab/pull/227#discussion_r1189963421

  • # qpi-related calculations
    ["qpi alpha RBC", float, "Specific refractive increment [ml/g]"],
    ["qpi alpha non-RBC", float, "Specific refractive increment [ml/g]"], 

• [ ] Solve the "pixel_size_qpi" problem if scale_to_filter. See comment here

[paulmueller]

:muscle: The most difficult thing to implement will probably be the handling of floating-point images (e.g. tests for RTDCWriter class).

After this is implemented, I should:

• [x] increment the dclab version on DCOR and make sure feature access through the API works
• [x] increment the dclab version in DCOR-Aid (so uploads to DCOR work properly)
• [x] increment the dclab version in DCKit and Shape-Out

[paulmueller]

I would also add the integrated phase (phase_int) which does not require any prior knowledge (radius or refraction increment).

[paulmueller]

Hey @PinkShnack I just had a quick look at https://github.com/DC-analysis/dclab/pull/225 and I think it would be best to do this thing step by step, split into multiple pull requests. The reason for this is that this will probably take a lot of time to implement and there will be other changes in dclab.

I would propose the following milestones / PRs:

1. Register the features in dclab (without any recipes how to compute them). This will allow me to slowly adapt all the software downstream to support QPI features. The changes made in this PR should be restricted to the dclab.definitions module. I assume you will also add a new "qpi" configuration section that holds the various parameters of the experiment.

2. Support reading ND floating-point arrays in fmt_hdf5 and fmt_dcor for phase and amplitude.

3. Support writing ND floating-point arrays in dclab.RTDCWriter. I believe this is not yet supported and should be properly tested. I think the latest versions of HDFView can also display floating point images. It would be nice if the commonly used colormaps (e.g. "coolwarm" for phase) would be supported in HDFView (but I doubt it). At this point, dclab can handle phase data, but it does not yet know how to compute them.

4. Implement ancillary features for computing the various QPI features. This involves implementing the methods (which you already started in #225) as well as subclassing from AncillaryFeature and computing the QPI features in one go (all at the same time, see my comments in #225). This is the least critical step, since all the features can also be computed using other software, such as dcevent, and dclab does not necessarily have to know how to compute it.

I think I haven't missed anything. But I believe once we reached step 1 and 2 we would already know whether there are any other obstacles.

[PinkShnack]

Sounds great. I will get onto point 1 now!

In the mean-time, shall I remove/close the PR #225 for now. By the time we get to it, everything will be changed, and it will just exist there for no reason.

[paulmueller]

Sounds great. I will get onto point 1 now!

In the mean-time, shall I remove/close the PR #225 for now. By the time we get to it, everything will be changed, and it will just exist there for no reason.

Yes, I think it's OK to remove it to avoid confusion :+1:

[paulmueller]

I am closing this issue here, because all the meta-work has already been done in #227.

My point 4 in my comment above should probably not be implemented in dclab (via ancillary features), but rather in a third-party software such as dcnum. The reason for that is that computing QPI features as ancillary features is just not feasible. Computing them in a step before using dclab makes much more sense.