Converted from SourceForge issue 3537822, submitted by philippjfr
Submit Date: 2012-06-25 15:24 GMT
The DSF_ distribution functions used to calculate FeatureMaps currently are being passed hardcoded definitions of their value scale during instantiation. In theory they should be able to inherit the range parameter of the Feature that is to be measured, as the valuescale in most instances is simply the reciprocal of the Feature.range parameter. While this assumption holds for most (or at least some) Feature/DSF function pairs, it isn't the case for spatial frequency preference (no range specified), corner angle preference (value_scale calculated from various parameters), position preference x and y (value_scale is not the reciprocal of Feature.range) as well as phase (value_scale simply 0.0 to 1.0) and in some instances orientation (unsure why).
Converted from SourceForge issue 3537822, submitted by philippjfr Submit Date: 2012-06-25 15:24 GMT
The DSF_ distribution functions used to calculate FeatureMaps currently are being passed hardcoded definitions of their value scale during instantiation. In theory they should be able to inherit the range parameter of the Feature that is to be measured, as the valuescale in most instances is simply the reciprocal of the Feature.range parameter. While this assumption holds for most (or at least some) Feature/DSF function pairs, it isn't the case for spatial frequency preference (no range specified), corner angle preference (value_scale calculated from various parameters), position preference x and y (value_scale is not the reciprocal of Feature.range) as well as phase (value_scale simply 0.0 to 1.0) and in some instances orientation (unsure why).