What options are there for interfacing with / controlling ImageJ/Fiji from another program?
I need to use some image filters that are available in Fiji. However, I cannot have Fiji be the centre of my workflow. I am using another system (scripting language) for that. I must manipulate some data in that other system, apply a filter to an image, get the result, then continue manipulating that image.
What are my options? What features does Fiji provide that make this possible?
In particular, is it possible to do this if the system I am using does not have a Java interface? It does have a C interface, and it can invoke command line programs.
For context: I want to interface Fiji with Mathematica. Mathematica does have a Java interface but it appears to lack support for some Java 8 features that ImageJ requires. I also don't know much Java and I am looking for a simple solution that I can set up quickly, rather than a long-term robust solution that requires a high initial investment.
If you can't run the ImageJ filters through Java integration, you may be able to write the necessary operations into an .igm macro and then get ImageJ to run it in headless mode.
Otherwise, it may be simpler to port the Java code for the particular filters that you need into a more convenient environment. ImageJ is primarily set up for GUI use, and Java/CLI/other integration can get messy very quickly.
Related
I have recently found a Matlab program (TraitLab) that I would like to try and use, but I do not have a Matlab license. Given that I thought GNU Octave and Matlab are mostly compatible, I tried to run it in octave, but the GUI way to run the program depends on loading a .fig file (now I know that I can use load to get the struct content of that file, but that does not make it a figure I can pass around to various GUI functions), and the headless way to run it reports many parse errors about
nested functions not implemented in this context
Is there an obvious way to get a function written for Matlab that shows these two symptoms to run under Octave?
I have downloaded TraitLab and it is obvious to me that it is a program that will need heavy modification for you to run on octave, which you probably don't have time (or possibly expert knowledge) to implement.
In this case you really only have two other options.
1) Write to the developers and ask them if they could re-implement their code in such a way to make it Octave compatible. I wouldn't hold my breath since it's an academic library, but it's always worth pointing out that there is demand for Octave compatible code. Also given this is old code, it's still worth contacting the stats lab in oxford, since they may have moved to a different codebase that might also suit your needs (e.g. I know that a lot of stats people in oxford have made the switch to julia).
2) In the meantime, if you really want to run this but you don't have matlab, find a matlab installation (e.g. from a friend, or at your university) and create a standalone-version using Matlab's "Application Compiler".
OR
Consider buying matlab. It has a reputation for being prohibitively expensive, partly because University-wide licences do cost an arm and a leg. But for personal use (especially if you are a student?), with the right licence and only the necessary toolkits, it's actually not as prohibitively expensive as you might think.
we start to write plug in for eclipse to work with some java frame work like hadoop (we want to edit hadoop eclipse plug in and merge it with other. our plug in must work in Linux operating system. Generally writing plug in for eclipse depend on operating system or not? if depend what benefits to write it for Linux?
Well, the previous answer is correct... in most cases. You should specifically check all the interfaces with the operating system.
SWT is a Java wrapper over native OS widgets. It behaves almost the same on all OSs, but not exactly. There are subtleties. For example, events that might be fired a bit differently, drawing of widgets, etc. My experience shows that you have to check on all OSs to be sure that it works as it should, especially if you are doing more complex UI rendering. In many cases I had to do some fine tuning to get it right. It is not a great deal of effort, but it should be considered.
Another issue is working with the file system. For example, make sure you are composing files paths correctly. It is always a good idea to test that part as well.
Eclipse plugins are platform independent (you are writing them in Java), unless your plugin requires some low-level calls to the operating system (i.e. JNI) or to invoke some tool found only in the Linux OS.
The only part of Eclipse tied - in part - to the OS is the SWT toolkit, since it's optimized for the graphic environment you are running it, but if Eclipse can run in the OS you are interested in, you should not be bothered by this.
What are the disadvantages of the Tk module compared to other solutions to create a GUI in Perl?
I toured the various gui modules for Perl recently, and here is my summary (disclaimer: ultimately I found that none of the existing modules met my needs so I started writing my own gui toolkit).
Tk - Decent to work with and the interface is very perlish. The gui itself is a bit dated looking, and doesnt take advantage of any of the operating system's native widgets (like filepickers). On most systems it will require a C compiler to install.
Wx - Difficult to work with, un-perlish interface. Large programs almost require a gui builder to keep track of everything. Support for os level widgets is mixed. Nicer looking than Tk IMO. Compilation is involved, requires installing several libraries, can be difficult to get running on windows. The assembly of programs is very procedural, and does not map cleanly to what the program will actually look like.
Qt - last I looked this module was more or less abandoned and only supports Qt3. I didn't try to install it, but i imagine it needs a compiler.
Prima - Similar to Tk it has a dated appearance. Requires a compiler.
W32::GUI - I ruled this out early since it is not cross platform.
XUL::Node / POE::XUL::Node - rather heavy dependency tree that includes C code. Seems unmaintained and I had mixed experiences getting it to install. Windows was a no go, OSX was a no go, it had limited functionality on OpenSUSE. It also only supports a subset of the XUL language.
I found that none of the existing gui toolkits made it easy enough to distribute your application to end users. It is ok to expect programmers to jump through the hoops of resolving library dependencies and compiling code, but end users aren't going to do that. So the first requirement I had was to be pure Perl.
Secondly, nearly all of the existing gui toolkits force you to work in a very procedural manner: Create a container. Create a packer for the container. Create an object. Set properties on that object. Add the object to the packer. Run the packer to fill the container object. Repeat.
Instead, I find that nested design (like HTML) is easier to follow for two reasons. First off, since objects are nested, there is no need to name everything (label_456, label_457...). Secondly, the structure of the program mirrors the structure of what is displayed.
So I started work on XUL::Gui, and its been coming along rather well. It is pure Perl, and only depends on core modules for ease of installation. It has one external requirement, which is that a recent (3+) copy of Firefox is installed. It uses the familiar design pattern of web development with nested tags styled with CSS. It is certainly at a level where you could write fully featured single window applications with it.
Hopefully this helps you to figure out which toolkit is best for your project.
Tk has not been developed in a very long time. ActiveState now recommends development with their Tkx toolkit, which provides a thin layer over TclTk. It means that themed widgets are possible. But, TclTk is still quite primitive compared with many other GUI toolkits.
I haven't tried XUL:Gui but it seems the way to go.
I have been trying to make work EZSIM with no luck, which is a software to build discrete event simulators in a graphical DOS environment. In this software, my simulator and many others (of the other people in the course I'm taking) don't work, but teacher's simulator (and examples of the downloaded files) does work.
So, I began to distrust of the software.
Do you know any software that resolves the same kind of problems but really works? It will be good if it is free, or I can download an evaluation copy or something like that.
If you don't know any software, do you know any library which might work? Preferably in C#, Ansi C, Java or Delphi.
This may be more than what you're looking for, but check out NS2. It's the standard for open source network simulations, and will allow you to simulate all kinds of network layer behavior.
I've also used JUNG in the past. It's very flexible, although it also doesn't offer much out of the box.
I used Möbius in my computer systems analysis class. It is free for educational use (which sounds like what you're doing). It's a Java GUI which generates C++ code.
The R package queuecomputer. queuecomputer is a computationally efficient method for simulating queues with arbitrary arrival and service times. There is a submitted paper on arXiv describing the algorithm used in the package. Examples can be found within the arXiv paper and the vignette. A web app based on the package is available at https://ace-ebert.shinyapps.io/queue_simulator_mmk/ .
Is there a general procedure for programming extensibility capability into your code?
I am wondering what the general procedure is for adding extension-type capability to a system you are writing so that functionality can be extended through some kind of plugin API rather than having to modify the core code of a system.
Do such things tend to be dependent on the language the system was written in, or is there a general method for allowing for this?
I've used event-based APIs for plugins in the past. You can insert hooks for plugins by dispatching events and providing access to the application state.
For example, if you were writing a blogging application, you might want to raise an event just before a new post is saved to the database, and provide the post HTML to the plugin to alter as needed.
This is generally something that you'll have to expose yourself, so yes, it will be dependent on the language your system is written in (though often it's possible to write wrappers for other languages as well).
If, for example, you had a program written in C, for Windows, plugins would be written for your program as DLLs. At runtime, you would manually load these DLLs, and expose some interface to them. For example, the DLLs might expose a gimme_the_interface() function which could accept a structure filled with function pointers. These function pointers would allow the DLL to make calls, register callbacks, etc.
If you were in C++, you would use the DLL system, except you would probably pass an object pointer instead of a struct, and the object would implement an interface which provided functionality (accomplishing the same thing as the struct, but less ugly). For Java, you would load class files on-demand instead of DLLs, but the basic idea would be the same.
In all cases, you'll need to define a standard interface between your code and the plugins, so that you can initialize the plugins, and so the plugins can interact with you.
P.S. If you'd like to see a good example of a C++ plugin system, check out the foobar2000 SDK. I haven't used it in quite a while, but it used to be really well done. I assume it still is.
I'm tempted to point you to the Design Patterns book for this generic question :p
Seriously, I think the answer is no. You can't write extensible code by default, it will be both hard to write/extend and awfully inefficient (Mozilla started with the idea of being very extensible, used XPCOM everywhere, and now they realized it was a mistake and started to remove it where it doesn't make sense).
what makes sense to do is to identify the pieces of your system that can be meaningfully extended and support a proper API for these cases (e.g. language support plug-ins in an editor). You'd use the relevant patterns, but the specific implementation depends on your platform/language choice.
IMO, it also helps to use a dynamic language - makes it possible to tweak the core code at run time (when absolutely necessary). I appreciated that Mozilla's extensibility works that way when writing Firefox extensions.
I think there are two aspects to your question:
The design of the system to be extendable (the design patterns, inversion of control and other architectural aspects) (http://www.martinfowler.com/articles/injection.html). And, at least to me, yes these patterns/techniques are platform/language independent and can be seen as a "general procedure".
Now, their implementation is language and platform dependend (for example in C/C++ you have the dynamic library stuff, etc.)
Several 'frameworks' have been developed to give you a programming environment that provides you pluggability/extensibility but as some other people mention, don't get too crazy making everything pluggable.
In the Java world a good specification to look is OSGi (http://en.wikipedia.org/wiki/OSGi) with several implementations the best one IMHO being Equinox (http://www.eclipse.org/equinox/)
Find out what minimum requrements you want to put on a plugin writer. Then make one or more Interfaces that the writer must implement for your code to know when and where to execute the code.
Make an API the writer can use to access some of the functionality in your code.
You could also make a base class the writer must inherit. This will make wiring up the API easier. Then use some kind of reflection to scan a directory, and load the classes you find that matches your requirements.
Some people also make a scripting language for their system, or implements an interpreter for a subset of an existing language. This is also a possible route to go.
Bottom line is: When you get the code to load, only your imagination should be able to stop you.
Good luck.
If you are using a compiled language such as C or C++, it may be a good idea to look at plugin support via scripting languages. Both Python and Lua are excellent languages that are used to script a large number of applications (Civ4 and blender use Python, Supreme Commander uses Lua, etc).
If you are using C++, check out the boost python library. Otherwise, python ships with headers that can be used in C, and does a fairly good job documenting the C/python API. The documentation seemed less complete for Lua, but I may not have been looking hard enough. Either way, you can offer a fairly solid scripting platform without a terrible amount of work. It still isn't trivial, but it provides you with a very good base to work from.