I am currently implementing a view that should be able to handle a table containing image data. So far I found PNGImageCell to be the only KNIME native type. Playing around with the straight forward ways (getImage) to pass the data to the view internal objects I ran quickly into memory problems. Now I was looking for a way to pass a refrerence to the image instead of the actual data, that would allow me to use bioformats and imglib2 to render the data on demand instead of loading it all in memory.
Then I stumbled accross the HCS-example on the KNIP page and noticed that in the interactive table view there is the image+ type. I could not find anything about it in the javadoc however.
I would be greatful for inputs how to tackle the problem.
what you mean with image+ type is probably the ImgPlusValue and its implementation ImgPlusCell, right? The ImagePlusCell/-Value is part of the Image Processing Extension for KNIME (community contributions) and the javadocs can currently only be find in the source code (e.g. here). The ImgPlusCell encapsulates an ImgLib2-image object.
If you need more help to get started with the image processing plugin, just let us know ...
yes, I was talking about the ImgPlusCell. I was assuming, that if I see this type in the Interactive Table View, that it must know about the extended type itself. Now I realize, that (logically) all the Cells are compatible with the base model. (just thinking on the keyboard ;)
Naturally I wan't to use the types of your KNIP plugin the ImageReference and ImagePlus. They work beautifully and keep the UI responsive.
But I would like to keep my plugin independent from the knip and for this reason I am looking for a viable solution witn the PNGImageCell builtin type.
However I got a bit confused now when I was trying to figure out how to get the Renderer of a DataCell to get a graphic Component without knowing which image type it is. The Interactive Data Table suggest this is possible... could you tip me off in the right direction?
after browsing the knip sources, I realized that the TableView takes care of the rending of without me having to add any additional dependencies in my plugin.
The ImageReference prooved the most efficient so far, since light for parsing (no data duplication) and reads the data only upon rendering.
The only thing I stubled across, is that I could not check the equlity of the Types nor could I use the DataTypes.isCompatible method, since the knip types do not implement the ImageValue interface. Instead I settled for this:
sorry for the late reply. Honestly, I don't really understand what you want to achieve. The ImageReference (if you mean the ImgRefCell, which will be obsolete in a long-term view, since imglib2-image-objects will do the job) is part of the community-image-processing-plugins and using it, requires dependencies on these plugins. The knip-types don't implement the core-interface "ImageValue", which doesn't make, at least in our opinion, much sense. But there are converters "ImgPlus to PNG Images" / "PNG Image to ImgPlus".
To speed it up a little bit, you can just call me, if you want.
let me explain the situation a bit more in detail. the HcsTools have a plate (heatmap) viewer, to visualize the readouts from a screen as heatmaps. It allows among other things to visualize the well details in a seperate window like this:
The idea was, that the viewer shows all the images it can find in the table corresponding to that particular well (line), so the image table in the lower half can have an aribitrairy number of columns. (PNGImages work too)
I hope that we manage to make the new version of the hcstools soon available, so you can have a look at all this on your own workbench.
The way this is implemented now, the WellViewer does not care what plugins are loaded and does not need a dependency on the knip plugin, to keep the hcstools as light and generic as possible. All it needs to know is if the column contains any kind of image content. From my perspective it would be ideal if the knime.core provides a basic interface that all the image types have in common and lets identify the image data. But as far as I have see, from the functionality of that method I can also understand, that from your perspective it didn't make sense to implement the ImageValue interface.
to be sure that I understand you right I try restate you question: a well in a plate (whatever data type or structure a plate is) is somehow associated with a table row (probably via the row id). This row contains possibly a couple of images whose need to be rendered in your WellView, whereas it's actually not clear, what data type an image represents.
My suggestion to solve this would be: Instead of enforcing the developer to use the interface "ImageValue" whenever an object is something like an image, you could just offer the possiblity that the user can select in the dialog of the WellView, which data types of the input table (ImgPlusValue, PNGValue, ...) should be shown in the view. So you don't stick to one particular interface and the user has more freedom (and could, for instance, add another ("non-image") data type to be shown there).
Your suggestion probably is the most robust solution. However I was a bit reluctant to add yet another tab in the configuration dialog. But without constraining the selection in the configuration dialog on image types the outcome could be a bit confusing. One could find the list of well attributes and in the lower table, without careful selection, one might find a (redundant) numerical value next to an image. So the problem of having a generic way of identifying image data remains still.
Well Viewer