[Octave-patch-tracker] [patch #9606] [octave forge] (image) New function integralImage

[Hartmut]

Follow-up Comment #4, patch #9606 (project octave):

Thanks for your second patch, Avinoam.

I have had a look at this V2 code from comment #3:

* The double quotes are fine, now.
* All tests still pass. (I still do not know if those test results are Matlab
compatible.)
* I have tried the two examples from the Matlab documentation page. Those gave
me identical results as the V2 patch. Here are the details, maybe you want to
include those as additional tests?

I = magic(5);
J = integralImage(I)
J_matlab = [0     0     0     0     0     0;
     0    17    41    42    50    65;
     0    40    69    77    99   130;
     0    44    79   100   142   195;
     0    54   101   141   204   260;
     0    65   130   195   260   325]
alle_gleich = all(all(J_matlab ==J))


[x, y, w, h] = deal(3, 1, 3, 2);
J = integralImage(I, 'rotated')
J_matlab = [0 0 0 0 0 0 0;
  0 17 24 1 8 15 0;
  17 64 47 40 38 39 15;
  64 74 91 104 105 76 39;
  74 105 149 188 183 130 76;
  105 170 232 272 236 195 130]
alle_gleich = all(all(J == J_matlab))
regionSum = J(y+w+h,x+w-h+1) + J(y,x+1) - J(y+h,x-h+1) - J(y+w,x+w+1)
regionSum_matlab = 133

* Matlab only accepts 2d images as inputs. Our V2 code also accepts Nd inputs.
(This is nothing bad, just a note.) Maltab then has integralImage3 for 3d
input images.
* The (only) main problem I still see it the run time for the "rotated"
version. Since it uses nested for-loops it runs horribly long. This basically
make the "rotated" version un-usable for real images! I see two ways to
proceed with this:
** Add a warning to the doc string of integralImage.m to say that the
"rotated" version will give right (i.e. Matlab compatible) results but has a
very bad speed performance, and therefore should better not be used for real
image processing. (Since the whole point of the function integralImage.m is to
speed up other calculations that use its output.)
** Eventuelly find a vectorised solution for the two nested for-loops in the
subfunction integralImage_rotate_2D. How to you like the following idea? 1.
accept the input image I. 2. generate a new "distorted" image I45 from it, by
(using a for loop) going through its rows and shifting each line sidewards by
one index, thus generating the new I45. 3. then use cumsum on I45 to generate
the final results (and maybe cut off some extra rows and columns). Advantages:
only 1 for loop (not 2 any more). And no real calculation in the for loop,
just shifting indices around. I hope this can be much faster.
** note: In Matlab (tested on I=magic(5000)) the result of the "rotated"
calculation is roughly 3times slower than the "upright" version.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?9606>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/