ToDesiredReceptorContrast method

[DavidBrainard]

a) I think this should be called something ComputeReceptorContrast, since what it does is compute the contrast that the specified direction produces with respect to the passed background and receptors. This might not be what was desired, especially after validation.

b) Should background be a required argument. Sometimes direction objects contain a background object. Perhaps a key/value pair to override the background in the direction object. Not sure, as I haven't fully grokked the whole direction architecture yet.

[JorisVincent]

a) This function actually does compute the desired receptor contrast, not the actual. It uses the SPDdifferentialDesired, which is instantiated on creation and (unless user-overridden...) stays unchanged after correction. This function uses the SPDdifferentialDesired of both the direction and the background. Thus, this function returns the 'desired' contrast, in that it is the receptor contrast that you would find if the direction and background produce exactly the SPDs that we want them to. In that sense, it is more of a theoretical/idealized contrast, than an actual one, because OLDirection-objects (for the most part) live in an abstract direction-space.

As a more general aside, I usually stick to the general naming convention of To.. for methods converting between object-types, in this case between an OLDirection object an a matrix of receptor contrasts.

[JorisVincent]

b) OLDirections-objects should not contain, or at least not functionally rely on, a background. This is the abstraction of OLDirection-objects that makes it possible to combine arbitrary sets of them (i.e. by adding them on top of each other). They are unanchored vectors in an abstract direction-space, so that you can 'move' any OLDirection onto the tip of any other (combination of) OLDirection-object(s).