I second you on this. For my current pipeline, I am doing registration using a plugin in ImageJ and then have to export all those images back to M. If there were an easier integration with other potentially powerful software then it will only make the pace of the work faster and seem a bit effortless.

The best approach then is thus two-pronged: (1) WRI should make it easier for M to interface with other programs (2) to extend the current capabilities of the core.

And I do hope that Charles Pooh is going to do what he said earlier that they are not abandoning Graph and associated functions. We are all aware how important graphs are - in their own right and as a useful data structure.

Last off-topic message in this thread—if you have figured out a way to control ImageJ/Fiji from within Mathematica, even in a very rudimentary way, please do send me an email. We can continue the discussion there then.

I am absolutely not arguing against adding more features to Mathematica. What I was trying to say is that Wolfram has zero chance of reaching parity with a tool like Fiji, which has a lot more resources and developers.

If Mathematica users can only use built-in stuff, then the Mathematica userbase will gradually get eroded to nothing in the next 10-20 years. However, if interfacing with other systems were embraced, if third-party package development were encouraged, then people could keep Mathematica the centre of their workflow while selectively using tools from other systems as needed.

FIJI is opensource (which is great) but the downside is that the developers are not paid.

At my institute, several research groups contribute to ImageJ. Some people are effectively paid to work on it. I am quite sure that ImageJ has vastly more resources available to it than Wolfram's image processing group. A huge amount of research funding goes into it.

Finally, many of these groups are developing new methods that let you do things that were simply not possible before. Wolfram will either integrate existing code (see how they use OpenCV and ITK internal;y) or implement existing, well-tested methods. You'll never get the state of the art from Wolfram (except perhaps in the form of third-party packages, but developing those isn't particularly encouraged). If you stick to Mathematica, and Wolfram doesn't start putting more effort into practical interoperability (i.e. not stuff like ExternalEvaluate in M11.3), then you'll be missing out soon ... I'm saying this as someone who would very much prefer to keep working in Mathematica, but is more and more often yanked out of the system because the tools I need are found elsewhere (including one instance with Fiji just today).

So what can one do in this situation? You can be an optimist like I was and hope that M will improve according to your dreams. You can even create your own interfaces to the systems you need, like I did. I put countless and countless hours into IGraph/M in the hope that the built-in Graph functionality, which the IGraph/M package relies on, will improve in the future. There are no signs of this happening, and I have almost lost all hope. Luckily, the image processing stuff is in a much better shape, but how can you be sure that it won't meet the same fate as Graph? And when that happens, do you really want to be locked into the Wolfram system because that's where your expertise and your existing tools (developed over many years) are, and there is no bridge to anything else (no interoperability)?

Can you clarify what you mean by 16-bit image display?

As for Fiji, I asked a question about interoperability here:

• https://mathematica.stackexchange.com/questions/180513/using-imagej-filters-directly-from-mathematica-through-j-link

Mathematica can't be expected to have everything Fiji has (especially special plugins!) but it would be great if I could use Mathematica as the centre of my workflow and still employ ImageJ for certain specific tasks. It seems that J/Link currently has some limitations that make it difficult to use ImageJ (and I now knowing much Java didn't help ...) I wrote to Wolfram Support about this and the feedback I got so far sounded encouraging (i.e. that they'd look into making things work). Let's see how that works out!

I also have a small LTemplate-based framework to make it easier to call SimpleITK functions directly from Mathematica. Sometimes SimpleITK has useful stuff that Mathematica doesn't (e.g. local histogram equalization, which I hope Mathematica will get in the future).

Occasionally I use MATLAB stuff too through MATLink.

Overall, what I am wishing for the most is better interoperability with other systems.

If some operation is built-in, that's obviously the best. But Wolfram only has limited resources. A high-quality interface to other systems, or toolkits that make it easier to build such interfaces (like LTemplate), can often give the highest benefit for the least amount of work.

Thanks Ali for sharing your wish list. It really helps to hear user feedback. Most of these were already on our todo list, we will add the missing ones and reprioritize all of them.

Also, here are a few things from the list that are immediately possible:

• Hough circles, as Sanders mentioned, we have the OpenCV version of it, it is waiting for a more complete/robust version that works in more cases
• Strahler Analysis can be done with morphological operations, look at Pruning
• morphological segmentation is the same as what we have under WatershedComponents
• lookup table application to images is available through ImageApply. Typically, for integer images a LUT is created as the pixels are processed anyways. One can also provide a specific LUT.

Hi Shadi,

I made an update of the post: included super pixel, GraphCut segmentation and a possible faster execution for Watershed opponents for 3D.

Regards, Ali

i know that the first one is already there, albeit a bit hidden:

ClearAll[oFindImageCircles]
oFindImageCircles[img_/;ImageQ@img&&ImageChannels@img==1,
{sizemin_Integer,sizemax_Integer},(*range of radii for circles*)
mindist_Real,(*minimum distance in between circle centers*)
thrCanny_Real,(*minimum canny edge strength---the function computes edge detection on the input*)
thrStrength_Real,(*minimum strength of circle (aka votes)*)
resolutionfactor_,(*between 0 and 1,how big is the hough array compared to the image*)
nmax_  (*max number of circles*)
]:=Module[{res},Needs["OpenCVLink`"];
    res=OpenCVLink`Private`$HoughCircles[img,1/resolutionfactor,mindist,(255*thrCanny),thrStrength,sizemin,sizemax];(*sorted by strength already*)
    If[Head@res=!=List,Throw@$Failed];
        res={{#1,#2},#3}&@@@Partition[res,3];
        If[nmax===All,
            res,
            Take[res,UpTo[nmax]]
        ]
];