[ImageJ-devel] frame grabber interface ?

[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.


On Thu, Jan 12, 2012 at 3:57 PM, Johan Henriksson <mahogny at areta.org> wrote:

>
> 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
>
>  --
> You received this message because you are subscribed to the Google Groups
> "ImageJX" group.
> To post to this group, send email to imagejx at googlegroups.com.
> To unsubscribe from this group, send email to
> imagejx+unsubscribe at 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.daerr at 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 imagejx at googlegroups.com.
> To unsubscribe from this group, send email to
> imagejx+unsubscribe at googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/imagejx?hl=en.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120120/30e7f5ba/attachment.html>