imagej
Refactor and generalize ThresholdNamespace
From https://github.com/imagej/imagej-ops/pull/435:
after a discussion with @stelfrich in person we decided to close this PR as the suggested code can be generalized and combined with the current threshold architecture. We want to have Condition object which then can evaluate arbitrary Conditions (especially no restriction on thresholds etc). This object will then be used in all threshold implementations (and potentially more implementations). We also want to have a View on thresholded images, rather can copying the images in the threshold method. This can then be done in the "burnIn" method as needed.
@lnyng in #392:
Notice that the existing framework using "Condition" is not very convenient to use and might be removed in the future.
Have the plans to replace the Condition(al) framework evolved since your comment, @lnyng?
When I started the branch I did not have the plan to remove the existing Condition based ops, but it seems that I eventually made a commit to remove them in the same branch. See 9fe0272087badcb49053c9c598dbcb8277745540. Sorry for any confusion.
When I started the branch I did not have the plan to remove the existing
Conditionbased ops, but it seems that I eventually made a commit to remove them in the same branch. See 9fe0272087badcb49053c9c598dbcb8277745540. Sorry for any confusion.
Thanks for the info, @lnyng. There's no common superclass for Conditions anymore, right?
Yes, now they only have general superclass like AbstractOp. Is there any special need for making one?
Is there any special need for making one?
We were thinking about generalizing parts of the ThresholdNamespace to use Conditions. While this looks like a good idea in general, it came up when trying to apply two thresholds to each pixel of an image. Our idea was to implement thresholds like 10 < value && value < 100 using a Condition in a MapView so that it only gets evaluated when pixel values are accessed.
@stelfrich I was vaguely afraid that removing Condition would somehow make use cases like that harder. But @lnyng and I thought that the set of interfaces was pretty convoluted and hopefully unnecessary, so we were a bit zealous in removing it. I still have not devoted enough brain energy to fully understand whether we truly need them, especially now that we use Java 8.
I still have not devoted enough brain energy to fully understand whether we truly need them, especially now that we use Java 8.
Can you (shortly) explain how Java8 can help? I'm currently playing with the Java8 interfaces an ops (one thing I'd like to do at the hackathon), but I don't understand how Java8 and Conditions relate?
Sorry, I have not given it serious thought. I can think about it at the hackathon, if you remind me.
See the forum topic Extract all pixels having certain value (IJ2 ops) for some discussion that might be related to this issue.
