I have labeled objects (e.g., outpouut from connected component). I would like to calcuate the distance transfrom (DT) on each object (cells/nuclei) and normalize the distance-transformed segment to [0,1]. After this I would like to merge the normalized DT objects together to generate the full field of view.
I think I found a way to put together a simple workflow to accomplish this except for the last part. I was trying to use the "GroupBy" node on by grouping on "Image Filename" and then aggregating on the normalized DT column using "Composite Image".
The problem is that, my normalized DT objects are of <floattype> ImgPlus. The "GroupBy" does allow me to retain the source format.
I'm using nIghtly KNIP nodes on KNIME Ver 3.2.0, WIndows 7 64-bit.
I can confirm that the "GroupBy" works for creating a <floattype> Composite Image using GroupBy.
But there is an another issue:
When I group segments after I apply some "arthimetic" to them then I get "box" overlap issue. For instance, my original segments looks like in "grouby_overlap_correct.png" but when I group the segments after manipulating them (groupby_overlap_issue1.png) I have some parts of the segments missing (overwritten).
I was wondering if there has been any fix to the issue of GroupBy->"Compose Image" for manipulated segmented objects.
I've put together a simple workflow (based on KNIP's Example Workflow) to illustrate this issue. You should be able to see the issue when you compare the "FOV_CroppedImg_dm_norm" with FOV_CroppedImg in the last node.
I finally had at least a quick look into the problem and opened an issue for that.
The problem is the following: If an image is assembled of multiple patches, only those pixels having the minimum value will be ignored (not documented, hence, no way for you to know that, sorry) and not written to the result image. That is, if all input patches are of double type only pixels with the minimum double value (i.e. a very small number - somewhere around -1.7*10^308) are ignored and won't overwrite pixels in the result image. All the others will be transferred and potentially overwrite other patches.
Till this issue is solved the following workaround may help:: if you, e.g., convert the distance map-patches into an UnsignedByteType, you will get the expected result (because pixels with 0 value are ignored).
