<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi all,</div><div><br></div><div>First of all, I am very reluctant to add any dependency to <span style="font-family: Monaco; font-size: 11px; ">imglib2-algorithms</span> core.</div><div><br></div><div>I admit that I did not really look into scijava-common so far, so I cannot really comment on how severe I think this would be.</div><div>I had a quick look and saw that scijava-common is itself not without dependencies. I found it depends on org.bushe.eventbus. On the eventbus website I found the notice:</div><div><span style="font-family: Verdana, Helvetica, Arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255); ">Update 3/2013: The EventBus has gone stale and is unlikely to be extended to other platforms. Suitable, though more primitive, replacements can be found for GWT (</span><a href="http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/event/shared/EventBus.html" style="color: rgb(0, 29, 126); font-family: Verdana, Helvetica, Arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255); ">GWT EventBus</a><span style="font-family: Verdana, Helvetica, Arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255); ">), Javascript (</span><a href="http://developer.tibco.com/pagebus/default.jsp" style="color: rgb(0, 29, 126); font-family: Verdana, Helvetica, Arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255); ">TIBCO PageBus - an OpenAjax Hub implementation</a><span style="font-family: Verdana, Helvetica, Arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255); ">) and Flex (</span><a href="http://www.spicefactory.org/parsley/docs/3.0/manual/" style="color: rgb(0, 29, 126); font-family: Verdana, Helvetica, Arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255); ">Parsley's Messaging</a><span style="font-family: Verdana, Helvetica, Arial, sans-serif; font-size: small; background-color: rgb(255, 255, 255); ">)</span></div><div>So would that mean dragging in a dead project as a transitive dependency?</div><div><br></div><div>As far as I can tell, the net.imglib2.multithreading stuff is a leftover from imglib1 times and I think I have mentioned several times that I would like to get rid of it… :-)</div><div>I guess that scijava-common ThreadService is more thought-through than the SimpleMultiThreading class. So replacing that I would see as an advantage.</div><div>In general, I think ExecutorServices are a good fit for multithreading pixel processing algorithms, along the lines of submitting a runnable for every line/plane/.</div><div><br></div><div>I see that you have a need for status reporting in ImageJ2 but I'm not sure that it should be in imglib-algorithms.</div><div>I would favour a way where we could keep the imglib2 code focused on processing pixels, not caring about framework issues.</div><div>In principle, status reporting can be performed before entering and after leaving a imglib2 "work-unit".</div><div>If fine grained reporting is required, then this would mean splitting up the work into smaller units and reporting in between.</div><div><div><br></div><div>In any case, even if we add scijava-common as a dependency, I strongly suggest to also keep non-reporting versions of the algorithms.</div><div>If noone is listening to the status reports thats just wasted computation time. I think the overhead will be quite high in some cases.</div><div>For instance in your forked ComputeMinMax algorithm you do some work on updating status for every single pixel, which I think is definitely overdoing it.</div><div><br></div><div>As a compromise I could image putting an empty protected method report() that is called periodically by the core algorithm implementation.</div><div>The JIT would hopefully just optimize that away if you use the core algorithm. Then for the reporting version you would have to extend the core algorithm and override report().</div><div><br></div><div>best regards,</div><div>Tobias</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Jul 26, 2013, at 5:09 PM, Mark Hiner <<a href="mailto:hinerm@gmail.com">hinerm@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div>Hi all (especially ImgLib2 developers)<br><br></div> Up until now, when running ImgLib2 algorithms on large datasets in ImageJ2, the UI was basically frozen for the complete compute time (e.g. when computing Min/Max values in the Brightness/Contrast plugin).<br>
<br></div> As of <a href="https://github.com/imagej/imagej/commit/dde5c3529e4b5daf78eb899a781635d4730ecb85">this commit</a> UI-based refreshing and event callback methods are now handled on a separate thread, allowing them to send UI updates (e.g. via the StatusService).<br>
<br></div> For the moment, to avoid adding a Scijava-common dependency to ImgLib2 algorithms, I <a href="https://github.com/imagej/imagej/blob/ffb3d651811089e582c0698701a1a1ea19151db9/core/data/src/main/java/imagej/data/minmax/DefaultMinMaxMethod.java">forked the ComputeMinMax algorithm</a> in IJ2 to use the StatusService to report computation progress.<br>
<br></div> Going forward though, we should agree on a long term solution:<br><div><div><br> A) imglib2 needs its own status reporting mechanism (Listeners and Events etc.)<br> B) it needs a SciJava context to use the StatusService <br>
C) we have to fork every core algorithm in ImgLib2 to add StatusService<br><br></div><div> If possible I would like to avoid C, but if it becomes a necessity it would be helpful if the algorithms were refactored for extensibility (having protected field accessors, for example).<br>
<br></div><div> I personally am in favor of B because it would limit code repetition and pave the way for further unification (Part of why I completely forked ComputeMinMax was to use the Scijava-common ThreadService, which has some - I think unnecessary - overlap with the SimpleMultiThreading utility class).<br>
<br></div><div> But I understand that adding this dependency is not a minor request, and care would have to be taken to limit the impact on performance.<br><br></div><div> So what do other people think?<br><br></div><div>
Thanks,<br></div><div>- Mark<br></div></div></div><div><br class="webkit-block-placeholder"></div>
-- <br>
-- <br>
Please avoid top-posting, and please make sure to reply-to-all!<br>
<br>
Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel">http://groups.google.com/group/fiji-devel</a><br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "Fiji-devel" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:fiji-devel+unsubscribe@googlegroups.com">fiji-devel+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/groups/opt_out">https://groups.google.com/groups/opt_out</a>.<br>
<br>
<br>
</blockquote></div><br></div></div></body></html>