Segment Cropper - multichannel images

I have an RGB image, once I run it through the segment cropper, only 1 channel remains. Is it something I am doing wrong, or is it just the node that has limited functionality? I guess I could split my image first into the 3 channels, do 3 segment croppers, joiners, and then the merger node, but this seems like a bit of a hassle.

Hi Luuklag,

is your labeling also 3-Dimensional? I think you would need the option "Expand Virtually" also in the "Segment Cropper".

See: https://github.com/knime-ip/knip/issues/304

One workaround for now: Labeling To Image -> Resizer -> Image To Labeling.

Cheers,

Christian

PS: I totally see that we need to be more flexible concerning transformations & co. Therefore with KNIP 2.0 there will be a entire transformation / Registration etc framework coming with KNIP - but this still needs some months...

Well the problem is just that it is a simple RGB image. I don't see why the segment cropper should handle them as three seperate channels instead of 1 image. Perhaps it is also possible to implement the selections that are implemented in the splitter node. So that we can say if they need to remain together, or not.

 

PS. Your work around is eleganter then mine: (screenshot)

Christian,

Could you please guide me in the settings of the Image Resizer node?

I am now using settings as in the screenshot. But this results in 9 channels instead of 3.

I found the problem. The Interactive Annotator keeps the image with 3 Channels, so my labeling also has 3 channels, however 2 are just blank.

Edit: I manually added the same selection to the other channels in the Interactive Annotator as well, so now the segment cropper also works on 3 channels. Perhaps you guys could program it in such a way that the IA automatically duplicate over a selected dimension, channel or time for example.

Good suggestion. I will open an issue! Thanks

So this node now gives me an error. I think the biggest problem is that there is a large part of the output that has a pixel value of 0, but is not black. So a wrong pixel value. In the screenshot this is the case for a bit less then the top 3 rows, about 2,8 rows. and 1 column.

 

Error for the node following the Segment Cropper. It happened with the ImageJ macro node, as well as with the splitter node.

 

2016-03-04 13:49:04,124 : DEBUG : Run$_KNIME-Worker-191 : ImageJ Macro : ImageJ Macro : 2:9 : Execute failed: java.lang.IllegalArgumentException: Interval must fit into src in SubsetViews.subsetView(...)
java.lang.RuntimeException: java.lang.IllegalArgumentException: Interval must fit into src in SubsetViews.subsetView(...)
    at org.knime.knip.base.node.ValueToCellNodeModel$1.getCells(ValueToCellNodeModel.java:399)
    at org.knime.knip.base.node.ValueToCellNodeModel.execute(ValueToCellNodeModel.java:525)
    at org.knime.knip.imagej1.IJMacroNodeFactory$1.execute(IJMacroNodeFactory.java:194)
    at org.knime.core.node.NodeModel.executeModel(NodeModel.java:563)
    at org.knime.core.node.Node.invokeFullyNodeModelExecute(Node.java:1146)
    at org.knime.core.node.Node.execute(Node.java:933)
    at org.knime.core.node.workflow.NativeNodeContainer.performExecuteNode(NativeNodeContainer.java:556)
    at org.knime.core.node.exec.LocalNodeExecutionJob.mainExecute(LocalNodeExecutionJob.java:95)
    at org.knime.core.node.workflow.NodeExecutionJob.internalRun(NodeExecutionJob.java:179)
    at org.knime.core.node.workflow.NodeExecutionJob.run(NodeExecutionJob.java:110)
    at org.knime.core.util.ThreadUtils$RunnableWithContextImpl.runWithContext(ThreadUtils.java:328)
    at org.knime.core.util.ThreadUtils$RunnableWithContext.run(ThreadUtils.java:204)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at org.knime.core.util.ThreadPool$MyFuture.run(ThreadPool.java:123)
    at org.knime.core.util.ThreadPool$Worker.run(ThreadPool.java:246)
Caused by: java.lang.IllegalArgumentException: Interval must fit into src in SubsetViews.subsetView(...)
    at net.imglib2.ops.operation.SubsetOperations.subsetview(SubsetOperations.java:172)
    at org.knime.knip.imagej1.IJMacroNodeFactory$1.compute(IJMacroNodeFactory.java:299)
    at org.knime.knip.imagej1.IJMacroNodeFactory$1.compute(IJMacroNodeFactory.java:1)
    at org.knime.knip.base.node.ValueToCellNodeModel$1.getCells(ValueToCellNodeModel.java:376)
    ... 15 more

I think I know the problem. I will take a look into it over the weekend! Which was the other node?

Splitter node, but perhaps more nodes are affected as well. If you want I can invite you to my workflow file on googledrive. ImageJan also asked for it.

Turns out I had an email adres of you, so I sent you an invite to the zip file.

I agree that there seems to be a bug in the segment cropper: if you view the image in the image viewer and inspect the pixel values by moving the mouse over the data, there is "value=0" shown on some regions where some gray value other than black is displayed.

I guess it's an issue with the offsets in the image metadata, since the region where that happens corresponds to the unlabeled region before cropping.

 

Regarding the other issue using the ImageJ Macro node, I will reply to you on the other forum thread in a minute.

Jan

 

it's actually not a bug in the Segment Cropper, rather in all other nodes as they don't handle min/max properly. I will go through all nodes and fix them. Additionally, we are heavily working on improvements concerning the image viewer. Suggestions welcome! ;-)

 

https://github.com/knime-ip/knip/issues/308

Additionally, we are heavily working on improvements concerning the image viewer. Suggestions welcome!

Certainly useful would be the ability to display several channels as composite view, as done in an ImageJ composite image.

And for intensity/contrast adjustment, I recommend taking Icy's histogram and color map as an example, where you have handles for dragging the min and max (or the whole display range) visualized on top of the (linear or logarithmic) histogram of an image; and in addition you can edit the color table (aka LUT) of each channel by dragging arbitrary handles on three lines (R,G,B). See attached screenshot or a live version of Icy.

I'm happy to paste this suggestion in a github issue as well, if you tell me where it fits best ;)

 

Have a nice weekend,

Jan

 

Certainly useful would be the ability to display several channels as composite view, as done in an ImageJ composite image.

Try marking several images in the Image Viewer. Is this what you mean? You can display these images next to each other or combine them to a single image (overlay).

And for intensity/contrast adjustment, I recommend taking Icy's histogram and color map as an example, where you have handles for dragging the min and max (or the whole display range) visualized on top of the (linear or logarithmic) histogram of an image;

We added the brightness / contrast panel of imagej for this purpose. Is this also ok? see: https://github.com/knime-ip/knip/tree/brightness_and_contrast

addition you can edit the color table (aka LUT) of each channel by dragging arbitrary handles on three lines (R,G,B). See attached screenshot or a live version of Icy.

We will add the possibility to select an arbitrary LUT per channel. However, we don't have a proper transfer function concept, yet. If you could open an issue for that after we merged our stuff and see whats missing from your side, this would be fantastic. Thanks! :-)

 

Certainly useful would be the ability to display several channels as composite view, as done in an ImageJ composite image.

Try marking several images in the Image Viewer. Is this what you mean? You can display these images next to each other or combine them to a single image (overlay).

I think what is meant is that with the Image viewer, from the RMB menu of a node. Once you double click on an image, you can always only see one channel at a time, instead of the normal full colour RGB image for example.

You can select the RGB renderer in the renderer selection.

Ah that nice, never knew it was there. Perhaps the way this selection process is done could be simplified, or it can be made more obvious that  this option exists.