As I wrote in another comment, the domain of problems for which Halide works is broader than imaging. I usually present it as "data parallel problems." In fact, I'd say the difference in domain between what Halide is good at and what OpenCL and CUDA are good at is not that significant in practice because those languages are basically C/C++ outside of kernel parallelism. (They are each adding some task parallelism facilities as well.)
"OpenCL implementation is also free to effectively merge the stages like in Halide."
I gave up relying on magic compilers a long time ago. And having worked in this domain for a long time I'm actually offended by people who write off the problem as simply a matter of a good enough optimizer. This has significantly held back both performance and portability in imaging. (And likely other areas.)
Halide is not magic, it is just a better slicing of the problem backed up by a good implementation. As always there is no free lunch but when it comes down to actually shipping this kind of code across a wide variety of platforms with great performance, it is a lot more productive than anything else out there.
The general domain of applicability is data parallel processing. There is very little that is image specific in Halide. So audio, dense linear algebra, some finite element applications, etc. would also be well within the domain.
This comment completely misses the fundamental innovation in Halide, which is a separation of "algorithm," a technical term denoting the part of the program that defines the computation, and "schedule," the part of the program which defines the mapping to hardware resources.
The end result is not like OpenCL, CUDA/PTX, or RenderScript. (All of which we regard as suitable target languages for Halide. PTX (CUDA's low-level assembly language) and OpenCL are currently supported.) As a concrete example, there is no explicit memory allocation in Halide and loops are often implicit. The overall character of Halide is that of a functional programming language.
As another example, segmentation violations due to errors in Halide code are impossible, barring bugs in the compiler implementation or errors in user provided C++ code, which Halide has no control over. Some set of bounds errors are reported at compile time and the rest turn into (efficient) assertion checks at runtime.
Schedules do get pretty low-level and writing them is difficult. Algorithms are generally a fair bit easier to write and while there is plenty to be done in improving the language, it is already a step up in productivity over e.g. OpenCL or even straight C++ for a lot of tasks within the domain of data parallel processing.
You should be able to link generated Halide code(1) with either compiler. (Using Halide generated code does not impose much at all in the way of requirements other than C-level ABI compatibility and basic library support.)
A fair bit of work has recently been done on making Halide work well on the Windows platform. We are erring toward requiring newer versions of Visual Studio however. (E.g. there are advantages on being able to rely on C++11 support for generating Halide code.)
I do not see any issues filed on things not working with Intel's compiler. Feel free to file one. Halide is an open source project and both bug reports and patches help a great deal.
(1) Halide can operate as either a Just In Time (JIT) compiler or an Ahead Of Time (AOT) compiler. Generally AOT is much more convenient for deploying in production. The end result of of compiling a single filter in Halide is an object file and a header file a single C-linkage function with all of its parameters passed in on the call. The minimal runtime is included in the object file and dependencies on libraries are also quite minimal, things like libc and pthreads. Functionality provided by the runtime can easily be overridden by providing one's own definitions for various functions, as weak linkage is used.
There is also a set of Python bindings, which can be used to write Halide code which is then AOT compiled. The AOT compiled object file can be linked into pretty much anything that can handle C functions either via direct linkage or a foreign function interface.
As I wrote in another comment, the domain of problems for which Halide works is broader than imaging. I usually present it as "data parallel problems." In fact, I'd say the difference in domain between what Halide is good at and what OpenCL and CUDA are good at is not that significant in practice because those languages are basically C/C++ outside of kernel parallelism. (They are each adding some task parallelism facilities as well.)