Hey folks,
when switching from the most recent official build to the most recent nightly build, I noticed changes in the way the size of my labelings is calculated. Please see the screenshot attached to this post to understand what I mean.
Why is it?
Why doesn't size equal the number of pixels?
Why can size be a floating point number?
Why is it impossible to have labelings with size smaller than 5 pixels?
Best,
Marc
Another thought:
Where features cannot be calculated, e.g. "LabelRegion was too small to calculate geometric features.", we get a NaN. Now, wouldn't it be more logical to get missing values instead? Not to mention how awkward dealing with NaN in the rule engine nodes is...
Where features cannot be calculated, e.g. "LabelRegion was too small to calculate geometric features.", we get a NaN. Now, wouldn't it be more logical to get missing values instead? Not to mention how awkward dealing with NaN in the rule engine nodes is...
Thank you for that great idea, I created an issue for this:
https://github.com/knime-ip/knip/issues/320
Thanks! :-)
Can someone please try to answer my initial questions?
Why is it?
Why doesn't size equal the number of pixels?
Why can size be a floating point number?
Why is it impossible to have labelings with size smaller than 5 pixels?
Because we now first dervice a polygon for each object and then calculate the size (and other properties) of the object. The polygon points are defined in real-coordinates and especially points lie inbetween pixels. therefore, sizes can differ from old calculations and floating/double precision. In contrast to that, before we simply used the number of pixels as the size of the object (and also to calculate other statistics).
Anyway, I agree it's not good to only offer the calculation based on polygons, as e.g. polygons may contain holes etc. So what we will add for the next release is an additional feature set where the calculations base on pixel values , like before. Like that the user can explicitly choose whatever he likes and is most suitable for his analysis.
Hello, when the Feature Calculator (Beta) encounters an image with no measurable features it skip it in the result table.
is is possible to configure the node as suggested by gab1one??
" Where features cannot be calculated, e.g. "LabelRegion was too small to calculate geometric features.", we get 'missing' values instead?
Was there a resolution to the issue reported: https://github.com/knime-ip/knip/issues/320
Thanks so much!!
If the above issue is not resolved, is there a workaround?
I need to have a table listing the missing measurements... :)
any suggestions? I could join a table built from the original JPG list with the measurement table but HOW can I join them so that the row corresponding to a JPG with no measurement is correctly matched?
thanks!
Hi avallepa
Here is a workaround-workflow which replaces all NaN with Missing Values.
thanks for the workaround! however I do not get NaN lines, the Feature Calculator just skip the lines were no areas are found....why?
Maybe I misunderstood you all the time!
Do you need a left (=top) outer join? The top table is the table with all rows and the bottom table has the missing rows. Left outer join will join the bottom table to the top table and if a join-id is missing a missing-row will be inserted.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.