Or possibly Fourier transform.

Or maybe not. I thought that found the center but doesn't look like it.

Yeah, a thousand cubed is a billion, must have misread that, and I guess if you're cloning arrays in nested loops you could create enough variables to use that much memory.

Of course, any time you find yourself nesting loops in any scenario you should take a step back and check what you're doing, especially if it's more than two levels and using the same data - there'll almost certainly be a different approach worth considering. Pretty sure detecting corner/outermost points doesn't require any nesting.

Oh I know, three nested loops is not a good idea with that many elements. I have no idea what I am doing though  8-O

I thought of one possible way around it. Just get them to upload an image of the chart without all the extra crap around it. I can easily (I think) find 4 points to match up the image then.

Is "them" the staff in a single lab/whatever who might actually listen, or does it include various clients who will blatantly ignore your hand-held instructions the moment you turn your back and go raise an issue claiming there's a bug in what you did despite it being a completely unrelated error that wouldn't occur if they did things how they were told? :@

Haha. Internal staff. Who are probably going to ignore my instructions and raise an issue despite not following instructions :D

I do have another plan though. Which I think would work up to a 9° rotation.

So. Iterate over points, pick 3, starting with two from top left and bottom right. Find the affine transform between those and my set of known points. Check how many points match.

Repeat, selecting second and third from top left with bottom right. Keep going for a bit then move in from the bottom left one with 1 and 2 from top left...

A quick check on my sample image and it's only 3000ish combinations. Not sure how fast affine warping is. I think that would pick out 3 easy to find points.

What's special about 9°?

It's more like 12°. Due to the order it detects the points while contour matching it would pick up the top two first (well last - it seems to work in reverse). Anything higher and the second point in the list would be the wrong point I want to match up to.

I think I have found a solution that works  :-O~~~ Assuming that the contour detection manages to pick out the 3 specific points that are needed.

It's a lot more computationally... er, computational. Somewhere between 10-30,000 iterations for the tests I've tried. I could probably optimise it further, some tests it's doing where the points are not far enough apart, or not the 3 points are in a straight line.

I still need to do some more testing, but initial tests are looking good.

I think I found why I was running out of memory in the big loop. OpenCV. Maybe cos it's wrapping C++ in Java. You can call release() on some objects to release it's memory.

Try Java Mission Control and/or Eclipse Memory Analyzer - helps find objects causing memory leaks. Or for stuff like seeing if you've got too many instances of something you only expect to have one of.

Eclipse!? No thanks :S What can I use with IntelliJ?

According to Stack Overflow it's because Java doesn't see the memory being used by the C++ classes so it doesn't know it's using as much memory as it is.

I tried another test, writing an image in a big loop and it crashed using too much memory. If I call release on the image before each loop finishes, the memory use doesn't go up and it works.

You can point Eclipse MAT at any JVM, local or remote. You don't need to be developing with Eclipse JDT to use it - the default download is a standalone non-IDE version.

It can't be used to analyse C/C++, which isn't surprising since it'll be a separate process and different memory structure.

Might be able to use tools from NirSoft or SysInternals to do that, if necessary, but probably not to the same degree of detail/interactivity.