i set up a LUT for xp, ixp, etc. helps a LOT.
edge case checking (ixp >= 0 && iyp >= 0) slows things down noticably. let's think about how to avoid this...
now, the main expense is *writing* back to outHist. doing 4 writes (up,down,left,right) instead of my '1 write test' in computeCell slows things down. (writing to 8-bit might help...)
avoiding x%sbin, y%sbin repeated calculation doesnt change speed at all
hmm, some of the outHist stuff has garbage outputs (really large numbers). hunting down the problem.
looks like the problem isn't in me incrementing outHist...even if I don't do any writes to outHist, I get some of these huge garbage values...
doiiii, i forgot to return hogBuffer
i'll probably want to do the 'inside-out' lerp strategy that I use in piggyhog. first, though, i'll do a test of voc5 vs our streamHog computeCell
streamHOG and VOC5 are pretty similar now, in terms of the computeCells code. not quite matching though (for most of the cells theres a nonzero diff). investigating...
aha, i introduced a bug into the voc5 version. (blocks[0,1] should be outHistWidth,Height ... not imgWidth,Height). fixed it, and now the results match except for the edges.
wrote a 'voc5 vs LUT diff test for lerp constants. found a bug...forgot to do ixp=floor(xp).
LUT and direct computation give same result now in my version of lerp.
the floor(x*sbin_inverse) is expensive compared to int(x*sbin_inverse).
the LUT helps, but the min/max stuff hurts. let's set this up with neither min/max nor 'if (ixp >= 0 && iyp >= 0)' stuff. instead, have some 'border cleanup loops'
omp is great for hiding latency inside computeCells
remove class variable lerp table...it's so small that there's no downside to computing it locally in each computeCell call
thinking about non-divisible-by-4 img sizes