Volume computation

[paulmueller]

@maikherbig I created a new branch for the volume computation and improved readability of the code. Your test runs, however:

• Does the parameter pos_x have any effect on the volume computation? I guess we should remove it?
  I added a test here that runs through perfectly for different values of pos_x: https://github.com/ZELLMECHANIK-DRESDEN/dclab/blob/volume_computation/tests/test_volume.py#L118-L139

• I saw that get_volume only works for contours that are counter-clockwise. It would be nice to test that and not rely on the contour being oriented the way it usually is (that might change): https://github.com/ZELLMECHANIK-DRESDEN/dclab/blob/volume_computation/dclab/volume.py#L67-L71

[coveralls]

Coverage increased (+0.3%) to 92.547% when pulling 930c6d2 on volume_computation into 29120a2 on master.

[coveralls]

Coverage increased (+0.3%) to 92.547% when pulling eebea6e on volume_computation into 29120a2 on master.

[coveralls]

Coverage increased (+0.3%) to 92.547% when pulling 22c0e80 on volume_computation into 29120a2 on master.

[coveralls]

Coverage increased (+0.3%) to 92.547% when pulling 22c0e80 on volume_computation into 29120a2 on master.

[maikherbig]

Pos_x is necessary as soon as the contour is not smooth. I used the following script to obtain a conotur with little random noise and when I compute Volume for different pos_x, i basically get random values:
"""xpos is necessary to compute volume of noisy conoturs"""
major = 10
minor = 5
ellip = get_ellipse_coords(a=major,
b=minor,
x=100,
y=50.0,
angle=0,
k=0.1)
#shift contour points slightly randomly left/right
a = np.random.uniform(low=-0.5,high=0.5,size=len(ellip[:,0]))
ellip[:,0] = ellip[:,0]+a
#Show the conotur
plt.figure(1)
plt.scatter(ellip[:,0],ellip[:,1])
plt.savefig('Contour+Random.png')
plt.close(1)

cx, cy = centroid_of_polygon(ellip) 
# no lists
v0 = get_volume2(cont=ellip,
                pos_x=cx,
                pos_y=cy,
                pix=1)
Vis = []
for cxi in np.linspace(0, 2*cx, 100):
    vi = get_volume2(cont=ellip,
                    pos_x=cxi,
                    pos_y=cy,
                    pix=1)
    Vis.append(vi)
plt.figure(2)
plt.hist(Vis,bins=25)
plt.title('Correct value is:'+str(round(v0,3)))
plt.savefig('Histo_Volumes.png')
plt.close(2)

Regarding the orientation (clock vs counter-clockwise): I think we should test somehow if the orientation of the contour is clockwise, but this is not urgent. I have never seen a contour that was written in a different orientation (for RT-DC data-sets)

[paulmueller]

This is scary. It looks like get_volume in its current implementation does not handle unevenly spaced contour data points. I see no reason why pos_x should have any effect on the computed volume.

Furthermore, as far as I can see, the contour data points in RT-DC are on a discrete grid. Are you taking points into account that are right above/below other points in the y-coordinate (green arrows below)?

I believe you should reimplement get_volume, optimized for RT-DC data. My suggestion for a straight-forward, discrete-only volume computation:

1. Determine the closure of the contour.
2. For each x-coordinate for each half-space, find all y-values of the contour.
3. Using these y-values as radii, compute the area of circular rings that are within the closure of the contour.
4. Sum up all rings and scale with pixel size / µm.
5. Average upper and lower half spaces.

This implementation has the advantage that it is

1. agnostic regarding clockwise/counter-clockwise contours
2. always gives the same result disregarding of pos_x

I do not wish to include the proposed implementation in dclab. Therefore, I am closing this pull request.

[maikherbig]

The algorithm has been shown and proven in
Advanced Mathematics and Mechanics Applications with MATLAB, 3rd ed., by H.B. Wilson, L.H. Turcotte, and D. Halpern, Chapman & Hall / CRC Press, 2002, e-ISBN 978-1-4200-3544-5. See Chapter 5, Section 5.4, doi: 10.1201/9781420035445.ch5
It works for arbitrary contours. Additionally I have tried it on thousands of data-sets and in every case the volume is perfectly correlated to area. Therefore I highly recommend this algorithm and would not suggest to implement something new that only works in "most cases".

[paulmueller]

Sorry, I edited my comment above. The algorithm I described will be more reliable than the proposed algorithm. The proposed implementation does not work for arbitrary contours, as you have shown yourself. There is a strong dependence on the lateral center position, which should not have an effect at all.

[maikherbig]

it works for arbitrary contours as long as the centroid of the contour is located in the origin. To place a contour in the origin pos_x and pos_y is necessary.

[paulmueller]

Can you explain why pos_x is necessary when the contour is not smooth? What does "smooth" mean and does it apply to the binary contours in RT-DC? How can you be sure that you get the correct value when you set the "center" position?

[maikherbig]

The algorithm uses the radius to compute volume. Therefore I was not surprised that the contour needs to be placed in the origin. Despite of that we can obviously obtain correct volumes for „smooth“ contours. I found that if a regular ellipse (no random noise) consists of several 10.000 points (so that would be ‚smooth‘), the algorithm would still return the correct volume, even if the x-position is not known. That seems to be a special case. For RT-DC data the contours are by far not so densely sampled and cells are also not looking like regular ellipses. Therefore it is necessary to put them into the origin. To ensure the alg. outputs the correct values I have done 2 tests:
1.) Area and Volume need to be correlated since both carry a very similar information. I computed the correlation coefficient for more than 10.000 different experiments (not 10k cells but 10k experiments which each have hundreds of cells) and obtained a median correlation of 0.93. Therefore one can clearly say that Area and Volume are expressing a similar information (cell size).
2.) In the reservoir, the cells should be very spherical. This allows a computation of the volume using V=4/3piR^3. I have compared the volume obtained analytically with the volume from the alg. Both gave very similar values.

I’m using this algorithm already for more than a year and I figured out a nice property:
-Currently we see that more deformed objects tend to have a higher area. Therefore we have a positive correlation between Deformation and Area and Cells at higher flow-rates have higher areas. This correlation is removed when using the volume as shown in the following example:

This is not only true for this one example, but the influence of deformation is in general much less for volume than for area. I have computed the correlation coefficient for >1800 different experiments:
Defo vs Area: median at ~0.4
Defo vs Volume: median at ~0.2

[coveralls]

Coverage increased (+0.2%) to 93.223% when pulling 59918c6 on volume_computation into c1854a8 on master.

[coveralls]

Coverage increased (+0.2%) to 93.223% when pulling 2491b40 on volume_computation into c1854a8 on master.

[coveralls]

Coverage increased (+0.2%) to 93.244% when pulling c5095d5 on volume_computation into c1854a8 on master.

[coveralls]

Coverage increased (+0.2%) to 93.198% when pulling 7dcb5dc on volume_computation into c1854a8 on master.

[coveralls]

Coverage increased (+0.03%) to 93.045% when pulling 3e31b35 on volume_computation into c1854a8 on master.

[paulmueller]

@maikherbig
The volume column is computed on-the-fly (when the user needs it). Since it does not require and user input, volume computation is done in the background in ShapeOut:

https://ci.appveyor.com/project/paulmueller/ShapeOut/build/job/spfk0m8s4fn2ck62/artifacts

Please check it out and let me know if there are any issues.

[paulmueller]

@maikherbig
I also added a method that forces a counter-clockwise orientation of the contours.

[maikherbig]

That is really nice :)
I have just a few issues:

• for RT-FDC Data-sets there comes the following errror message:
  

• The whole point doing all this math stuff was to make it robust for non-convex contours. Therefore I would suggest to remove "The method assumes that the contour is convex." from the Notes in the docstring

Thanks a lot Paul!

[paulmueller]

I removed the note. Could you please give me the RT-FDC data set with which it doesn't work?

[paulmueller]

@maikherbig
Thanks for testing. I fixed the problem. It seems like the contour column had one more event than the pos_x column - something that might be worth investigating? I hope there is not another offset I have to take into account. Do you have the corresponding images to check whether the contours match?
https://ci.appveyor.com/project/paulmueller/shapeout/build/1.0.619/job/uayec387q472nwxx/artifacts

[maikherbig]

Now everything (Volume comp. and Contour+Picture display) works perfectly. I have tested a couple of older and newer RT-DC and RT-FDC Datasets.
Cheers!

[paulmueller]

Great, thanks again for testing.