BlackHatJ produces unexpected results

[ctrueden]

The following macro:

newImage("Untitled", "RGB ramp", 64, 64, 1);
makeOval(16, 18, 35, 27);
setForegroundColor(255, 255, 255);
run("Fill", "slice");
run("Select None");
run("BlackHatJ ", "x=2 y=2");

produces this result:

But with odd numbers (e.g. x=3 y=3 or x=5 y=5) the result is all black. And with even numbers (e.g. x=4 y=4 or x=6 y=6) the result is the same as above.

These results also differ from those produced by ImageJ Ops:

Using the following script:

// @OpService op
// @Dataset image
// @OUTPUT Object result
import net.imglib2.algorithm.neighborhood.HyperSphereShape
shape = new HyperSphereShape(1)
result = op.run("morphology.blackTopHat", image, [shape])

[ctrueden]

Strangely, with the Clown sample image, odd values seem to work.

[joheras]

Since the bridge between ImageJ and OpenCV only works with RGB images that is probably the reason to do not obtain the correct result in the case of the image generated with the macro. I will work on the problem to fix it asap. 2017-03-14 16:17 GMT+01:00 Curtis Rueden <notifications@github.com>:

…

Strangely, with the Clown sample image, odd values seem to work. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFMQGxJGhylfDR-tEsj-lRSynmH0U3DCks5rlq90gaJpZM4MctDS> .

[ctrueden]

@joheras If you make the examples implement PlugInFilter instead of PlugIn and override the setup method to only accept RGB data, then that would certainly be sufficient. I actually just came across a perfect example of this sort of change today; see here (except there it accepts only 8-bit gray i.e. DOES_8G rather than RGB i.e. DOES_RGB).

Alternately, if you want to get fancy, you could enhance the converters to automagically make 8-bit data into RGB for the purposes of OpenCV.

This issue, though, is actually not about RGB, but rather me questioning why different x/y values do not produce different results, as well as why even/odd has such a marked difference. I am no expert on morphological operations though, so it may be that there is actually no problem here.

[joheras]

In fact that is what I have done, I have re-implemented the plugins to implement PlugInFilter instead of PlugIn and overrided the setup method to only accept RGB data. In the short future, I expect to implement the bridge for other kind of data to avoid this kind of problems. 2017-03-15 19:33 GMT+01:00 Curtis Rueden <notifications@github.com>:

…

@joheras <https://github.com/joheras> If you make the examples implement PlugInFilter instead of PlugIn and override the setup method to only accept RGB data, then that would certainly be sufficient. I actually just came across a perfect example of this sort of change today; see here <bonej-org/LocalThickness@bc5f8fb> (except there it accepts only 8-bit gray i.e. DOES_8G rather than RGB i.e. DOES_RGB). Alternately, if you want to get fancy, you could enhance the converters to automagically make 8-bit data into RGB for the purposes of OpenCV. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFMQG5fykpJc0E3XTqDrT_nGBwyBnV7Rks5rmC8TgaJpZM4MctDS> .