Hi Stephan,<br><br>Thanks for your reply about AWT in ImgLib2, and sorry my reply here is so long delayed.<br><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

<br></blockquote><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">If dependency on AWT in imglib2-core is not wanted, then we should move<br>
the entire display package into a new sub-project imglib2-awt.  However,<br>
the sole purpose ScreenImage interface being to return an awt Image it<br>
cannot be stripped from AWT dependency.<br></blockquote><div><br>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.<br>

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

<br>Latest code is on the lee_headless-ctr branch here:<br>   <a href="https://github.com/imagej/imagej/blob/lee_headless-ctr/core/data/src/main/java/imagej/data/display/DefaultDatasetView.java">https://github.com/imagej/imagej/blob/lee_headless-ctr/core/data/src/main/java/imagej/data/display/DefaultDatasetView.java</a><br>

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

<br></div><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br>
The display package in its current for is all about generating an AWT<br>
image.  Do you have an alternative display in mind?  Is there any code?<br></blockquote>

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

<br>For example, Apache Pivot has its own Image hierarchy, including a bitmap Picture class:<br>    <a href="http://pivot.apache.org/2.0.1/docs/api/org/apache/pivot/wtk/media/Picture.html">http://pivot.apache.org/2.0.1/docs/api/org/apache/pivot/wtk/media/Picture.html</a><br>

<br>And on Android, we would probably need a Bitmap object:<br>    <a href="http://developer.android.com/reference/android/graphics/Bitmap.html">http://developer.android.com/reference/android/graphics/Bitmap.html</a><br>
<br>
All of this is doable at some later date!<br><br>Regards,<br>Curtis<br><br>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:<br>

<br>src/main/java/net/imglib2/display/ARGBScreenImage.java<br>src/main/java/net/imglib2/display/ScreenImage.java<br>src/main/java/net/imglib2/display/UnsignedByteScreenImage.java<br>src/main/java/net/imglib2/outofbounds/OutOfBoundsMirrorFactory.java<br>

src/main/java/net/imglib2/sampler/special/OrthoSliceCursor.java<br><br>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.<br>

<br><br><div class="gmail_quote">On Thu, Mar 15, 2012 at 8:18 AM, Stephan Saalfeld <span dir="ltr"><<a href="mailto:saalfeld@mpi-cbg.de">saalfeld@mpi-cbg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> Note that we need to extract all code referencing AWT into a new component<br>
> and confine AWT's use to that component. So we might need to either move<br>
> ScreenImage out to, say, imglib2-awt or strip it from all mentions of<br>
> AWT's classes and interfaces.<br>
><br>
<br>
</div>If dependency on AWT in imglib2-core is not wanted, then we should move<br>
the entire display package into a new sub-project imglib2-awt.  However,<br>
the sole purpose ScreenImage interface being to return an awt Image it<br>
cannot be stripped from AWT dependency.<br>
<br>
The display package in its current for is all about generating an AWT<br>
image.  Do you have an alternative display in mind?  Is there any code?<br>
<br>
Thanks and best,<br>
Stephan<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
</div></div></blockquote></div><br>