GroupBy for floattype ImgPlus column

Hi, 

Here is what I'm trying to do:

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. 

 

Thanks,

 

Reddy

Hi Reddy,

we will have a look and answer you tomorrow (latest)!

Best,

Christian

Hi Reddy,

thanks for reporting! Fixed, i.e. float, double and long are now available as well.

So far available in the nightly build and soon with the next bug-fix release.

 

Martin -

Thanks for a speedy fix.

I'll fetch the nightly build (07/16/2016 I pressume) and will check it out.

Thanks,

Reddy

Hi -

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).

 

Best,

Reddy

Hi Reddy,

Martin is on vacation this week. He will take care next week when he is back!
 

Best,

Christian

Martin/Christian -

 

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.

 

Thanks,

 

Reddy

 

 

Hi Reddy,

sorry for the very late response!

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).

Hope that helps a bit.

Best,

Martin

Martin -

 

Thanks for opening a ticket/issue. I'll follow it on GitHub.

 

I'll see if I can use your workaround (as a temporary fix). 

 

Best,

 

Reddy