I'm sure it has nothing to do with ram speed or file versions, the difference is to big. The only thing that could explain this away is some extremely effective catching but then your 10 seconds would be to big.

But when I look at my 1st mockup it did a 191MB file (zip) in 277 seconds. Your code isn't optimized so the results it gives on my PC are actually rather accurate when compared to my 1st test, yours being a bit slower (again what would be expected of php). There is nothing running on my PC that could be bottle-necking the tests either.

To give an insight in why I believe the results from your script on my pc can be trusted compared to my last test (33sec/2.1MBs/70mb file) I'll explain the method:

First thing I did was switch to FastPixel. What this does is direct I/O with the in-memory byte array that holds the color data of a Bitmap object. That method alone will vastly outperform any drawing via php. Because the overhead is next to none and it doesn't cause the kernel to start using half of cpu time. Next thing I did was optimize its get/setpixel methods so that it no longer requires a color to be passed allowing me to write directly from the data buffer to the bitmap buffer -> byte to byte in memory = FAST. That also saves 2.560.000 Color objects from being created at 1600x1600px. Some other tweaks were done to FastPixel to result in less "x = new y()" statements, again saving 2.560.000 cpu intensive operations for each. All this gets executed in parallel (new threads) for each image to put all cores to work.

I think we both know that this method should outperform any php implementation by far because if php would be faster its the same as saying that php is faster than the language it was written in, C. But I'm gonna leave an open mind for your results because if it isn't some flaw I want to know why you are getting those low times. So do let me know if you can think of something.