Major design decisions: Pixel datatype support? C or C++?

[cdeil]

Pixel datatype support

We need at least int and double, for speed / memory footprint we probably also want int32 and float32.

C or C++

We are unsure if we should use C or C++.

Advantages of using C++:

• No pointers, std::vector does the memory management.
• Templates allow many datatypes (int, uint, double of various precisions) with ease

Disadvantages of using C++:

• Making it build everywhere is probably a bit harder?
• Portable python bindings (different systems, compilers, python versions) are harder? A bit, much?

Code simplicity and speed should be identical with C or C++.

Is it true that the only C solutions to supporting several datatypes are:

• Duplicate the code for each data type or
• Use macros (would that work?)

If so I would strongly suggest we use C++ templates.

Before we decide on C or C++, and for guidance on making a good API, let's briefly look at a few popular C and C++ libraries for linear algebra and image processing. This is what a quick google search turned up (mostly C++, only some C):

• http://www.boost.org/doc/libs/1_48_0/libs/gil/example/convolution.cpp
• http://www.fftw.org/
• http://numpy.scipy.org/
• http://www.gnu.org/software/gsl/ (partly C++)
• http://www.imagemagick.org/
• http://eigen.tuxfamily.org/
• http://arma.sourceforge.net/
• http://seldon.sourceforge.net/
• http://fftwpp.sourceforge.net/ (even has 2D FFT convolution)
• http://opencv.willowgarage.com/wiki/
• http://cimg.sourceforge.net/

[pflaumenmus]

yes, I also see some advantages in C++: better structure due to classes and less redundancy due to templates

But if we use C++, we must not resize the vectors, but instead define their dimensions at creation time.

The only problematic function is "Convolve" and there are only few lines that are depend on the data type of the image. So we could also pass void pointers to that function and then define a function pointer:

convolve(void pointer data, data_type) function_pointer p if data_type == FLOAT p = read_float if data_type == INT p = read_int end

The functions read_int and read_float would get an address and read the following 1,4 or 8 bytes and return them as int or float, respectively. If the compiler correctly inlines it, it should be fast.

In general, there are several possibilities with C to not duplicate the data, but many of them involve an IF statement and we don't want that.

How would we integrate it to root, by the way? It would be a waste of memory to copy all our TH2 to arrays or vectors, then do the ringBG and then copy it back. Or do you have an idea?

[pflaumenmus]

we could also define a data type in a header file:

// comment the line below, if dealing with double data

define DISCRETE

ifdef DISCRETE

typedef int TYPE;

else

typedef double TYPE;

endif

and then in the source

void Convolve(TYPE _img1, TYPE _img2, int w, int h, Ring *ring) ... img2[y][x] = (TYPE) S; ...

and so on. So we have generic code, you just have to switch the comment of that line:

define DISCRETE

[cdeil]

I think we should set it up so that we can build a library that supports ints and floats (possibly of various sizes).

Kind of like ROOT comes with TH2I, TH2F, TH2D and the user doesn't have to rebuild ROOT to get the types he wants.

So how about using C++ templates and then instantiating a few default types when building the library?

[cdeil]

For ROOT integration I think we should simply a converter that copies TH <-> std::vector and back. At least for the cases we are working on (and I guess most others) memory is not a big constraint, but speed is, and the time it takes to copy is very small compared to the time it takes to correlate.

This utility function should be in a separate file so that users that don't have / care for ROOT can build the library too.

[cdeil]

Just for fun:

http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/I_did_it_for_you_all

[pflaumenmus]

yes, good posts :-)

templates.. I thought you wanted C code for portability and the python wrapper, or not? for root, we could convert, of course, but it is not very elegant. If we have 10.000 * 400 bins à 8 byte, then we lose already 32 MB - and the binning can always be finer and the maps bigger. What about the function pointers? That is easy and clear and would solve all the problems. The memory access functions would be in different files and thus, we can have a pure C version, a C++ version and a root-version. I can explain that on monday, if you like.