Support arbitrary data types

[matze]

Up to now, processing multi-dimensional single precision floating point data is the main target of the UFO framework, however support for element types other than that has been proposed. Here are some issues that we (@tomago, @rshkarin, @ashkarin, @kamer16) should discuss before implementing it:

• [x] What types are absolutely necessary? I suppose it's at least double.
• [ ] How should arbitrary kernels know about this? My first idea would be to compile the kernels with -Dbtype=double and use btype for all global arguments.
• [ ] What should we do if a certain type is not supported by the device? Especially double is a big problem on GPUs. We could convert implicitly but that's ... not what people would expect.
• [ ] Where do we set the desired buffer type? Per task? For the entire graph?

[tfarago]

Good to see this here.

1. absolutely necessary is ushort because of the cameras. But the more the merrier
2. exactly
3. I know, then don't execute the graph and tell the user why and what they can do. If I do high-precision calculations I certainly don't want the framework to implicitly change my data type.
4. Per task I would say, another attribute in the ufo-buffer structure. Use case: camera data (ushort) -> filtering (2x float, or, better yet, complex) -> backprojection (float) -> normalization (ubyte) -> writer

[matze]

Concerning number 4: I suppose it's up to the task to decide which type to use rather than the user?

[tfarago]

Yes and no, e.g. flat correction has to output floats, sure. But what if the user wants it as a double? Or what if we have a normalize node? Then if I set it up to normalize to [0..255] I can convert it to ubyte from float or so. But for this we can make a converting node and the user can just use that one if they want full control.