Erm.. what's up?
Yes it should be the same version, but how exactly is it different?

btw: I am scared @ confused by your memory allocations (particually the second pointer allocations(?) )
What's wrong with

RawImage = new float[(NumPixelsX+1)*NumPixelsZ]

? 1d arrays make much more sense to manage
Why the +1 on x?

Well I took another look. The deallocation does look correct, yes. (I ergh think, could somebody else back me up on this?)
It's probally more of a common sense problem. like accidently accessing the memory after it's been freed? check your program run structure thoroughly
(infact chuck the whole thing out & rewrite it all neatly object based you'll save yourself so much trouble in the long run)
Fraid I can't say anything else other than that & how damn ugly it is :/ soz

The amount of memory the function is allocating more than:
4 * NumPixelsZ * NumPixelsX * NumPixelsX
which for NumPixelsX & NumPixelsZ being say 500 is around half a GB (I'm guessing what the real values might be). I'd say it is at least possibly failing to allocate it.

Initialise all of the pointers to NULL where they are defined (or in the constructor). Check that each pointer is not NULL after allocation, or use the option to make allocation failures throw an exception if possible.

Take out the two unnecessary "for (int i = 0; i < ImageDimX; i++)" duplicate loops, and deallocate everything in the reverse order to alocation (my personal preference):

You can reduce the number of calls to new if you want, by piggybacking allocations of the same type (which I've started to do below) Pros: better cache usage, speed, deallocation simplicity etc. Cons: you gotta make it obvious to anyone maintaining your code that some things do not need to be explicitly freed.

#ifdef DEBUG#define UNINITIALISE_PTR(x) do{ (x) = 0xCCCDCCCD; }while(0)#else#define UNINITIALISE_PTR(x)#endifbool AllocateReconMemory(){	FilterCoeff = new float[1 + 5 * NumPixelsX];	SpreadingTerm = FilterCoeff[1 + NumPixelsX]; //Piggybacked allocation	InputData_ZeroPadded = SpreadingTerm[2 * NumPixelsX]; //Piggybacked allocation	RawImage = new float*[NumPixelsX + 1];	for (int i = 0; i < NumPixelsX + 1; i++)		RawImage = new float[NumPixelsZ];	ProcessedImage = new float**[ImageDimX];	for (int i = 0; i < ImageDimX; i++)	{		ProcessedImage = new float*[ImageDimX];		for (int j = 0; j < ImageDimX; j++)			ProcessedImage[j] = new float[NumPixelsZ];	}	return true;}void FreeReconMemory(){	for (int i = 0; i < ImageDimX; i++)	{		for (int j = 0; j < ImageDimX; j++)			delete [] ProcessedImage[j];		delete [] ProcessedImage;	}	delete [] ProcessedImage;	UNINITIALISE_PTR(ProcessedImage);	for (int i = 0; i < NumPixelsX + 1; i++)		delete [] RawImage;	delete [] RawImage;	UNINITIALISE_PTR(RawImage);	delete [] FilterCoeff;	UNINITIALISE_PTR(FilterCoeff);}

You should also add a lot of asserts to your array access lines of code to ensure that you're not writing past the end or beginning (if you haven't already).

My UNINITIALISE_PTR macro ensures that you can detect any attempt to access the memory after it has been freed (in your debug version of course)

NumPixelsX + 1 definately seems logically wrong. The + 1 shouldn't need to be there. There should at least be a comment in the code to explain why it is present if it is absolutely necessary.

Hope that helps. It's not ideal, but an improvement anyway.

I knew someone would say that :-)

Absolutely! It can seem a questionable optimisation, but it has it's place. simple code alocating a 2D array could be done with just 2 alocations instead of potentially 1000's. It can make a big performance difference to BOTH the allocation and the deallocation, as well as to cache access patterns, and reduces OS memory tracking overhead.

I probably shouldn't have mentioned it though as it should really only be used when really needed, as the maintainability decrease is quite possibly not worth it usually. This was a bad example of it's usage though.

Yeah that could be an inline function I suppose.