Vis_Map
This is a feature that is part of most sensors (MFile being an exception) that changes the order of bytes delivered to fit some other property. There are currently three modes availables, normal (called zig-zag by some), nGram (first byte determines position on the X axis and the second byte determines position on the Y axis) and hilbert.
Hilbert (depicted above) is good at preserving spatial locality across rows, which makes it easier to identify regions of different types.
nGram (or bigram or tuple) is good at highlighting structure, for identifying types and subtypes. It is non-reversible in the sense that the mapping structure do not preserve the order in which values were mapped.
A big downside to this approach is that it changes the layout of the sampled data, this means that tools that rely on spatial position need to be aware of this and be able to remap (which is not possible with some functions) or be solely dependent on data in the frequency domain (which is only affected by the sampling window dimensions). As a rule of thumb, no translator is able to account for this state.
- Having the mapping stage be part of the sensor rather than a GPU stage was, in retrospect, a complex design choice that perhaps costs more than it is worth. To lessen the damage, the option of also providing some remapping on a GPU level (which, in a sense, is already done in the 3D views) will be provided.