[ImageJ-devel] Questions about imglib2

[Curtis Rueden]

Hi Stephan,

Thanks for your reply about AWT in ImgLib2, and sorry my reply here is so
long delayed.


> If dependency on AWT in imglib2-core is not wanted, then we should move
> the entire display package into a new sub-project imglib2-awt.  However,
> the sole purpose ScreenImage interface being to return an awt Image it
> cannot be stripped from AWT dependency.
>

It is not yet clear to me whether we should fully isolate the AWT
references in imglib2 core. We may indeed want to do so at some point, but
it is certainly not urgent.

The main design issue we are facing in ImageJ2 is that we need a concrete,
UI-agnostic DatasetView implementation that keeps a CompositeXYProjector
object internally. Right now we are keeping an ARGBScreenImage internally
too, but doing so introduces an indirect AWT dependency, which we have
worked hard to avoid.

Latest code is on the lee_headless-ctr branch here:

https://github.com/imagej/imagej/blob/lee_headless-ctr/core/data/src/main/java/imagej/data/display/DefaultDatasetView.java

Probably the easiest way to avoid this issue will be to generalize the
"screenImage" variable away from an ARGBScreenImage specifically and just
use IterableInterval<ARGBType> instead.

So, the only real potential reason to migrate ARGBScreenImage into a
separate imglib2-awt project would be if it causes problems when targeting
other platforms, such as compiling for Dalvik (i.e., Android). But at the
moment, anticipating any such issues is mere speculation—we shouldn't worry
much until we try it and then we can address any actual problems one by one.


> The display package in its current for is all about generating an AWT
> image.  Do you have an alternative display in mind?  Is there any code?
>

I think the current ScreenImage implementation is good. We may want to
rename it to "AWTScreenImage" though if we want its function to be
unambiguous.

We may also eventually need to create additional ScreenImage-like
interfaces for other styles of image objects. It would probably be OK for
them to live in the respective UI-specific packages of ImageJ2, though.

For example, Apache Pivot has its own Image hierarchy, including a bitmap
Picture class:

http://pivot.apache.org/2.0.1/docs/api/org/apache/pivot/wtk/media/Picture.html

And on Android, we would probably need a Bitmap object:
    http://developer.android.com/reference/android/graphics/Bitmap.html

All of this is doable at some later date!

Regards,
Curtis

P.S. Another reason to fully isolate AWT from imglib2 core is that it is
already so close to being AWT-free. Only five classes currently include any
AWT references:

src/main/java/net/imglib2/display/ARGBScreenImage.java
src/main/java/net/imglib2/display/ScreenImage.java
src/main/java/net/imglib2/display/UnsignedByteScreenImage.java
src/main/java/net/imglib2/outofbounds/OutOfBoundsMirrorFactory.java
src/main/java/net/imglib2/sampler/special/OrthoSliceCursor.java

Of course, the first three are just the aforementioned ScreenImage stuff.
And the other two don't actually use AWT at all—they just reference
java.awt.Image in the javadoc.


On Thu, Mar 15, 2012 at 8:18 AM, Stephan Saalfeld <saalfeld at mpi-cbg.de>wrote:

>
> > Note that we need to extract all code referencing AWT into a new
> component
> > and confine AWT's use to that component. So we might need to either move
> > ScreenImage out to, say, imglib2-awt or strip it from all mentions of
> > AWT's classes and interfaces.
> >
>
> If dependency on AWT in imglib2-core is not wanted, then we should move
> the entire display package into a new sub-project imglib2-awt.  However,
> the sole purpose ScreenImage interface being to return an awt Image it
> cannot be stripped from AWT dependency.
>
> The display package in its current for is all about generating an AWT
> image.  Do you have an alternative display in mind?  Is there any code?
>
> Thanks and best,
> Stephan
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120419/5773d74f/attachment.html>