Wow, I’m not sure where that is coming from. I didn’t mean to insult you, I don’t know why you’re saying I’m dismissing your advice, or that I’m a newbie, or that I have an ego that I can’t swallow. I’m sorry my reply makes you feel that way, I really do, I appreciate the effort open source contributors spend on projects like this, and I appreciate you even just taking the time to reply to my question.
I’m trying to understand WHY what I do doesn’t work using the TM_CCORR, because the docs don’t mention anything about transparency needing SQDIFF, and my approach is very similar to the code samples I find in the codebase. There’s a clear “weird” behaviour with Infinity/NaN values and normalization that trips over it, I’m trying to understand why that is, to learn, and maybe to help someone else in the future to bump into the same problem by adapting some docs or finding this post. Your advice to use another method doesn’t help me understand what I do wrong or the Infinity/NaN values, I didn’t mean to dismiss it, but it felt like “you’re trying A, which doesn’t work, you should try B” while I’m trying to figure out why A doesn’t work 
Another reason I maybe wasn’t receptive enough of you proposal to move from TM_CCORR to SQDIFF is because I’m working on a project where thousands of images/matches should keep working as today, not changing the “match percentage”, and I’m afraid that changing the match method will introduce a difference in behaviour in other use cases. We use TM_CCORR when not using transparency, and I now only want it to work using transparency, not sure if it’s smart to keep using TM_CCORR when there is no transparent match needed, and SQDIFF for transparency.
I will adapt my code to use SQDIFF as you suggest and report back soon, but if this magically works, I will still be stuck wondering why my original code does what it does and figure out how to introduce this without breaking existing functionality.
I hope I’ll pass your test