Посмотрел я ту тормознутую функцию... Там в цикле для каждого пикселя происходит три деления (видимо, для каждого компонента цвета), а деление, как известно, самая тормознутая операция всех времён и народов компьютеров.
Но это ещё пол-беды. Настоящая беда программистов из NWC в том, что это деление происходит примерно вот так:

a1 = 7FFFFFFFh/A1;
for(int x = 0; x < X; x++)
{
   for(int y = 0; y < Y; y++)
   {
    mass1[x*Y+y] = mass2[x*Y+y]/a1;
   }
}
Заметили, что сначала находится обратная величина, а потом на эту обратную идёт деление? Этот алгоритм можно оптимизировать и скорость его увеличится в разы, т.к. вместо деления нужно будет использовать умножение, плюс коррекция (а может и без неё прокатит). Если убрать начальные проверки длины и высоты на 0, то можно даже, наверное, вместить в имеющийся размер.
Вот тока я никогда не правил екзешники.