frame grabber interface ?

[Adrian Daerr]

Hello,

This mailing list does not seem to have received any message in a long
while, but it seems the right spot to drop this question: what are
current positions, plans, ideas, general feelings about capturing
images from a camera with ImageJ[A2] ?

In NIHImage there was Command-G.

In ImageJ there is a few plug-ins that can capture frames from certain
sources (QuickTime, Twain,..), with each its own interface. And of
course there is MicroManager. And maybe I have overlooked other stuff.

I am currently looking into the possibility of adding grabbing from
GigE cameras directly into ImageJ (which would somewhat ease our
workflow here at the lab, where we currently have a separate grabbing
app that records to the disk), at least on Linux, and was wondering
how that would be best implemented.

Do you think there is room/need for, or advantages in, having a nice
generic/unified grabbing interface in a future version of ImageJ ?
Do you think all things (hardware-)interface related are best written
as extensions for MicroManager, and ImageJ will continue to interface
with that ?
Would it be easy to provide just some simple interface (RMI ?,
FIFOs ?) which would enable external, possibly native applications to
send image data to ImageJ, for real-time display / processing /
capture ?
Should I just write yet another grabber plugin using the Java Native
Interface to talk to some native part ?

Searching for 'camera', 'grabber', 'acquisition', etc on a few ML
(fiji-devel, imagejx notably) has not turned up anything, so I figured
I'd ask if I can start this in a usefull direction for the whole
community.

cheers, Adrian

[Johan Henriksson]

This mailing list does not seem to have received any message in a long
while, but it seems the right spot to drop this question: what are
current positions, plans, ideas, general feelings about capturing
images from a camera with ImageJ[A2] ?

In NIHImage there was Command-G.

In ImageJ there is a few plug-ins that can capture frames from certain
sources (QuickTime, Twain,..), with each its own interface. And of
course there is MicroManager. And maybe I have overlooked other stuff.

disclaimer: I have contributed to micromanager so I might be biased.

but: my feeling is that all plugins but micromanager should be dropped, and if a camera is only supported as a IJ plugin but not in MM then that driver should be added. MM already provides a unified interface. there is no need to put a unified interface on a unified interface, if MM already covers the other hardware.

+ it is a lot of work to redo what MM already does...

/Johan

--
-----------------------------------------------------------
Johan Henriksson
PhD student, Karolinska Institutet
http://mahogny.areta.org  http://www.endrov.net

[Curtis Rueden]

Hi Adrian,

I agree with Johan. Micro-Manager went to a lot of effort to create a unified interface for acquisition, so best would be to use it. The ImageJ2 and Micro-Manager teams are working together in areas of overlap, and I expect will do so more as both projects mature. The Micro-Manager developers gave a lot of initial feedback and suggestions regarding difficulties they encountered with ImageJ1, which has really helped guide the development of ImageJ2. So the plan is for Micro-Manager to take advantage of IJ2's flexible architecture, once things are far enough along.

In short, I don't see Micro-Manager going away any time soon, so it makes a lot of sense to base your acquisition code there. Then you get ImageJ integration for free.

Regards,
Curtis

P.S. The ImageJX mailing list has quieted down because the imagej-devel mailing list has grown and become more of an external list. The name ImageJX made more sense when we were discussing the idea of a new ImageJ, whereas imagej-devel makes more sense now that we are actually doing it. I have updated the mailing lists page (http://developer.imagej.net/mailing-lists) to reflect that. Sorry for the confusion.

--
You received this message because you are subscribed to the Google Groups "ImageJX" group.
To post to this group, send email to ima...@googlegroups.com.
To unsubscribe from this group, send email to imagejx+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/imagejx?hl=en.

On Thu, Jan 12, 2012 at 7:55 AM, Adrian Daerr <adrian...@gmx.de> wrote:

Hello,

This mailing list does not seem to have received any message in a long
while, but it seems the right spot to drop this question: what are
current positions, plans, ideas, general feelings about capturing
images from a camera with ImageJ[A2] ?

In NIHImage there was Command-G.

In ImageJ there is a few plug-ins that can capture frames from certain
sources (QuickTime, Twain,..), with each its own interface. And of
course there is MicroManager. And maybe I have overlooked other stuff.

I am currently looking into the possibility of adding grabbing from
GigE cameras directly into ImageJ (which would somewhat ease our
workflow here at the lab, where we currently have a separate grabbing
app that records to the disk), at least on Linux, and was wondering
how that would be best implemented.

Do you think there is room/need for, or advantages in, having a nice
generic/unified grabbing interface in a future version of ImageJ ?
Do you think all things (hardware-)interface related are best written
as extensions for MicroManager, and ImageJ will continue to interface
with that ?
Would it be easy to provide just some simple interface (RMI ?,
FIFOs ?) which would enable external, possibly native applications to
send image data to ImageJ, for real-time display / processing /
capture ?
Should I just write yet another grabber plugin using the Java Native
Interface to talk to some native part ?

Searching for 'camera', 'grabber', 'acquisition', etc on a few ML
(fiji-devel, imagejx notably) has not turned up anything, so I figured
I'd ask if I can start this in a usefull direction for the whole
community.

cheers, Adrian

--
You received this message because you are subscribed to the Google Groups "ImageJX" group.
To post to this group, send email to ima...@googlegroups.com.
To unsubscribe from this group, send email to imagejx+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/imagejx?hl=en.

[Adrian Daerr]

Hello,

Thanks Johan and Curtis for your comments (and thanks to Johan for
his
efforts in keeping MicroManager compiling on Linux). It does make a
lot
of sense to take advantage of MMs infrastructure for hardware
interfacing, and I am reassured to hear that the MM-IJ tandem is
intended to last into the IJ2 era. I'll go that way then.

thanks,
Adrian

p.s.
Thanks also, Curtis, for the update on this mailing list. I am
subscribed to the imagej list, fiji-users and fiji-devel, but somehow
I
missed imagej-devel in the process :-)