Pitfalls

In the following we will list common pitfalls:

OpenGL clamps values. The CPU implementation does not!
Type "deduction" from target image.
For integer types the result between CPU and GPU can have a difference of 1. This may happen if the result of the expression has a fraction of 0.5
Computation is performed in the original space. If assigned to an integer image, the storage value of the computation will be rounded to the closest storage value.
res.img()->setShift(0.3);

res.img()->setScale(1.2);

// Note: res.img()->originalToStorage(3.0) == 3.96

// Each pixel in res will get a storage value of 4 (result above rounded to the closest storage value)

// Thus the original values will be 3.0333333333... instead of 3.0;

// Basically the value will be the closest value in the image of the mapping N -> R : n -> storageToOriginal(n);

makeArray<short>(res) = 3.f;

ImFusion::ImageMath::makeArray
auto makeArray(TypedImage< T > &img, bool ignoreShiftAndScale, MagFilter magFilter, Wrap wrap, const vec4f &borderColor)
Convenience function to create an array leaf (needed as until c++17 there is no template type deducti...
Definition Array.h:664
Evaluation on the CPU is in double while it is float on the GPU. (original image space)
Use auto ONLY if you want to store the expression!
Aliasing: Be careful when you use block views. As long as the operations are affecting the very same pixel in read and write operations everything is fine. Otherwise you can have aliasing.
The debug version of the CPU expression can be rather slow. Do not consider this as reference. In Release + Optimization most of the code can be inlined. In addition any asserts are disabled then as well.