Thanks for your comments. I did anticipate some frustration that I didn’t go down the ImgLib2/ImageJ2 route, so please let me explain my reasoning.
At the time when I started this work, it was not clear that QuPath would become a software application in its own right - nor that it would be open source. Furthermore, ImgLib2 and ImageJ2 were at a considerably earlier stage of development. Since I was working on my own in an applications-focussed group, I had to act quickly to show results with the techniques and technologies I knew best, and which were ready for what I needed.
Given these pressures and uncertainties, and that I am not a group leader with the authority to steer the direction entirely on my own, the practical alternative would not have been a grander, collaborative open source project with interoperability from Day 1, but more likely switching to a commercial solution for our analytical needs. I hope you agree that, even if QuPath doesn’t suit your preferences 100%, this would be worse.
If I were to start it again today, ideally working with a team of people and having agreement from all interested parties that the result would be open source, the ImgLib2 road would certainly be one I’d explore enthusiastically. But I hope you understand that, for a range of practical reasons, it wasn’t an option for this version of QuPath. Maybe it is for a future version - and that’s one of the reasons why I was so keen to push for it to be open source at all.
However, this isn’t the only explanation for my choices. There is also a more technical side that makes me hesitant even now - albeit one that might be addressed if I knew ImgLib2 (for example) better.
This is the issue of determining the right trade-offs. For QuPath’s digital pathology applications, the analysis is typically applied to 2D RGB images, often up to 40 GB in size - and the users are frequently pathologists, or at least not image analysis specialists. While some measure of flexibility is important (and QuPath does have some support for other data types, e.g. z-stacks, fluorescence), I believe it’s essential to handle the kind of data most common for the primary application as well as possible - and it’s also essential that the software can be picked up quickly by the target users, most of whom do not have any interest in linking up to other tools. I would therefore argue that, in this specific case (but not in general), it’s more important that the software is efficient and user-friendly than that it is generic and interoperable. Of course it would be better to achieve all of these, and other people might have chosen different trade-offs from the ones that I did.
With that in mind, QuPath makes the detection and interactive classification of many hundreds of thousands of objects fast, interactive and (relatively) easy. It can generate and summarize millions of measurements in minutes, and display these in a wide variety of ways (including colour-coded measurement maps) while smoothly panning and zooming around an image that’s frequently much too big for the RAM (these videos are a bit out of date, but show the idea).
Achieving this required a lot of attention to optimisation tailored to the application, image caching, representing objects as efficiently as possible etc. What’s more, QuPath can be scripted and linked up with ImageJ, OpenCV, Weka and MATLAB today, and I’d be very happy to link it with other tools in the future. I don’t know if this would have been achieved as quickly, with my finite time and abilities, if I had chosen to base more of the core of the application on existing frameworks (which may not have fully existed when I started). I do expect that the benefits of doing this would also have necessitated some sacrifices, and given the differing goals of QuPath and the other tools built on these frameworks, perhaps even some conflicts.
Certainly I do not intend for QuPath to be a disconnected island. I also don’t think every design decision I made was optimal, and I continue to develop, revise and improve the code. I also hope that community involvement will help strengthen the software in time, and interoperability is one way to do that.
But I also think that much of the bioimaging community is already served quite brilliantly by the tools that exist and are being developed - with ImageJ2 among the most important of these - and it doesn’t need me to try to create another one along these lines. My hope is that QuPath offers something fundamentally different, and which goes some way to addressing the needs of a sufficiently wide range of users for whom there is no other accessible, open source solution currently available. Having worked most of my career with fluorescence microscopy, I can attest that the field of pathology is quite different.
Anyhow, sorry that was a bit long - but hopefully you understand my position, my openness (and enthusiasm) for interoperability where it makes sense, and why I took the decisions that I did so far.
To answer your question, I don’t personally plan the kind of integration you describe imminently, primarily because of a lack of time and other immediate priorities, but it is a discussion I would like to have - if you or any on the imglib2/imagej2 side have an interest as well.
My personal view, which I think is only slightly different to yours, is that it is great to encourage people to create and release open source software that will hopefully be of benefit to others, in whichever way works best for them. For many, this can really be a struggle in an academic context, and I think a lot of researchers find it easier to do so in a less-then-fully-connected way at first. To me, that’s no bad thing - it can also have benefits in terms of offering new and distinctive approaches.
Once a new software island is known to exist, anyone who wants can take a boat there to look around… and afterwards to consider whether it’s worthwhile to work together build a bridge
Anyway, thanks for your thought-provoking comment… and patience, if you read this far.