Hi Volker,<br><br>Halide looks quite cool, and is a very similar idea to other recent libraries, including the OPS package of ImgLib, and ImgLib in general. In the future, perhaps we could create a Halide bridge, making it easier to invoke such algorithms on data within ImageJ. But of course it must wait until someone is using it and/or needs it.<div>

<br></div><div>Regards,</div><div>Curtis</div><div><br><br><div class="gmail_quote">On Tue, Aug 14, 2012 at 2:22 AM, Volker Baecker <span dir="ltr"><<a href="mailto:volker.baecker@mri.cnrs.fr" target="_blank">volker.baecker@mri.cnrs.fr</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
I came across this work which I think could be interesting for some of you.<br>
<br>
<a href="http://people.csail.mit.edu/jrk/halide12/" target="_blank">http://people.csail.mit.edu/jrk/halide12/</a><br>
<br>
A citation from the side:<br>
> We propose a representation for feed-forward imaging pipelines that<br>
> separates the algorithm from its schedule, enabling high-performance<br>
> without sacrificing code clarity. This decoupling simplifies the<br>
> algorithm specification: images and intermediate buffers become<br>
> functions over an infinite integer domain, with no explicit storage or<br>
> boundary conditions. Imaging pipelines are compositions of functions.<br>
> Programmers separately specify scheduling strategies for the various<br>
> functions composing the algorithm, which allows them to efficiently<br>
> explore different optimizations without changing the algorithmic code<br>
<br>
Volker<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>
</blockquote></div><br></div>