Re: That's not the Answer to Your Question

"The lack of appreciation of the essential factors involved in block
processing is entirely yours."

Absolutely, and that lack of appreciation is warranted if block processing
is unnecessary to solve the OP's speed problem. And, it is you, not I, who
is remiss for not trying to determining the exact cause of the OP's speed
problem before pontificating on block processing.

Meditate on this:

OP: "as processing pixel in a vertical fashion was _very_ slow (0.31 vs.
0.009 for the horizontal)."

How is it that I am the only one who suspects an outstandingly dumb error
in the OP's code?
I have never encountered anywhere near such a large disparity between
horizontal and vertical processing speeds on a personal computer, even
with sloppy code. (Which begs the question, what kind of computer does the
OP have?) How is it that I am the only one to ask to see his code without
block processing? Since the OP was uncooperative in providing the relevant
information that I seek, I now suspect the OP made the whole thing up to
jerk people around for fun.

"And also annoyingly by modifying the header you break the threading on
some newsreaders that
don't handle followups too elegantly."

You should blame the newsreaders instead of using me as a scapegoat for
your annoyance. You apparently missed two corrections to my post. See
them here:

http://www.talkaboutgraphics.com/group/sci.image.processing/messages/66962.html

"> Also, min(j+2,N)and
min(i+2,N) are unnecessarily recalculated for every block.

Very few optimising compilers are quite so dumb but there are better ways
to cater for odd N."

I wouldn't know, because I haven't done a survey of compilers, but I
suspect calculation in the loop might be part of the C or C++ language
standard because the philosophy is to give the programmer control. I'll
ask some programmers and get back to you.



.

Quantcast