## GradientField: Unify all gradient representations

Currently, there are 4 ways a gradient can be represented:

- The regular GradientField
- The SAbber-format, a GradiendField-child containing a MD5-hash of the used reference
- The WeightedGradField-cluster for adding, subtracting, multiplying ...
- The vector-representation that is used for the controll-loops

Those don't need to be completely separated objects as they contain basically the same properties. Therefore, a unification of those to a single class would simplify the handling of gradients in wide parts of the code. Here are some thoughts:

- The MD5-hash of the reference can be a regular field. If it is an empty string, the Read-vi could return a "false" flag, otherwise true.
- Weights were removed earlier as they are not needed for most applycations. If they were saved in a separated array however, this can stay empty until it is actually needed, not eating up unnecessary ressources.
- The vector-representation could be generated on the fly within a class method if needed. On the other hand, a vector can be written and transformed into a regular gradient field, checking if every value is NaN or not.

ADDITIONALLY: What about diagonal gradients? (dxy and dx-y) They would be calculated from dx and dy for the improved Southwell reconstructor (see #17). On the other hand, if the evaluation of the SID4/QWLSI-sensor is implemented, actual diagonal gradients will be measured! Corresponding fields will be needed. Therefore, why not include them in the GradientField class? As with the weights, it might be beneficial to use a separated array so there won't be wasted ressources if those fields stay unused. A CalcDiagGrads.vi could be implemented to auto-fill those arrays from dx and dy for the improved southwell-algorithm.