Thanks a lot for your advices Juan!
These changes effectively improved the response speed by at least 2 (when one frame was previously processed in 3 minutes, it now only takes 1 or a little less).
Changes :
– (1) added resolution parameter 100 in the configure() method
– (2.1) modified in fuzzyRGBTest() :
for (int i=0 ; i<deltaIntensityVar->numberOfTerms() ; ++i)
deltaIntensityVar->removeTerm(i);
to
for (int i=numberOfTerms()-1 ; i>0 ; --i)
delete deltaIntensityVar->removeTerm(i);
– (2.2 – 2.3) added in fuzzyRGBTest() :
if (fuzzyEngineRGB->hasRuleBlock("RuleblockRGB"))
delete fuzzyEngineRGB->removeRuleblock("RuleblockRGB");
Considering your suggestion of having multiple engines and avoid as much as possible their modification inside the for-loops, this would mean having I*J*K different engines, that is, K engines per pixel, one per codeword (K is not equal for all the pixels).
Though this would not really be a problem in terms of development (I could either set up a pointer to an Engine into the codeword struct or manage a vector of I vectors of J vectors of K Engines), but do you think it would cause a memory problem? Is the overall Engine structure heavy in memory?
Anyway, I think this would be profitable this way.
design a single fuzzy engine that takes into account the variable intervalBrightness, and create rules that modify your current rules only once,
I am not certain to understand what you mean. The Brightness variable depends on brightnessMin and brightnessMax values, which are codeword values. Thus, rules have to change for each codeword in to take new thresholds into account in the new rules.