PHP imagecolorallocation producing incorrect color?

A problem with a simple explanation and fix that’s surprising hard to find an answer for on google. In php, when working with certain images imagecolorallocate() will not return the color you want, and instead return any old color. It’s a rather frustrating problem on the surface, as your code is correct and the result the server ives you is not. but after a little troubleshoot the answer hit me in one of those moments of clarity you hear alcoholics talk about. It’s all a problem of the images color allocation table.

See, the problem is that an image in certain formats (GIF and PNG (8 bit) and there are probable other, less common formats that are susceptible) Store every color in the image in a table. This is what the command imagecolorallocate modifies to give you your color. Specifically it ads one to the end of the table and return it back to you. This is the root of the problem. See, if the image is full color (relative to the limited number of colors they can have) imagecolorallocate can’t add a new color to the images color allocation table, and instead returns a random color (which I’m sure is not random, it’s probably just the last color in the table). So thats the problem, whats the solution?

Simple, remove a color from the color table. Not I suggest doing this prom Photoshops “Save for Web and Devices..” feature as it will be able to re-jigger the color table to still look good, randomly pulling a specific color and turning it black (which can be done entirely from PHP) runs the risk of ruining the image. You can over-ride the Photoshop palet size option simple by typing in the box next to it, 255 will leave you one more color to fill, if you want to use multiple colors then you need to adjust you images pallet size accordingly.

Prevent slow data in AJAX (abstract concept thereof)

UPDATE 1/29/11 I’ve since found a simpler solution to this problem and have a real working code example about it in this post: Prevent stale AJAX data in jQuery.

So at work I noticed an off bug in one of my old ajax scripts (on of my first in fact). The script may receive an older result after it has received a newer one (because it’s for some reason or another that command processed slower than the one after it). This is only really an occurrence when a script makes lots of requests in a row, for instance a live typing search result (ala google instant). This problem never occurred before with the faster scripts using a smaller test base, and if fact wouldn’t be a problem if I had a button to press to activate the script, instead of the onkeyup event. Thats the simple solution, but not the nice looking one. I’ve though of a solution, and I’m sure there are a bunch more, and better, methods to achieve the same thing and if I think of a better one I’ll post it.

Okay so the concept of this (which at this time is only a concept because due to the nature of the problem, it’s not the simplest thing to test locally, but I will do so soon, probably tomorrow) is to get the timestamps of the data back and compare them again the curent one. Now I usually have the AJAX script call back pre-formatted code ready to be plopped into the page where needed, so in such a case you need to send the data and the time as two separate variables, probably via json because it’s simple and effective for this sorta thing. For the time sent back the simplest way would be seconds since epoch since the newer the entry the bigger then number leaving a simple greater than check, if it’s bigger then display the results and update the time, of not then you discard the data and the time.

That method should work great for determining if the data coming from the server is old, if your sending it from the script to a server and also want the newest of the new then it’s even easier. have javascript get the time (getTime() would work) and have it have it to the db, simple having the script compare those timestamps to each other before writing to make sure that for whatever reason (although unlikely going in this direction). One this to remember if you also having PHP write this timestamp is that the javascript function will return the time in milliseconds, the PHP time() function returns time is seconds since epoch. Conversion will have to be made accordingly (and to be safe, round the javascript time down by dividing it by 1000 and flooring the number)

I’ll update this one I’ve actually done a real work test, but nothing in here seems like it’s going to cause any problems in implementation.

PHP-Lively Refresh Fix

PHP-Lively is a php/javascript/ajax live chat script that allows users to chat with vistors on their site. It’s like that feature that nearly all large business sites have but not quite as fully fledged and somewhat buggy. It’s also free, not $99 a month like the most common chat service is.

I was installing PHP-lively into a site after testing it on my personal server and noticed it was not automatically refreshing the view. So if someone typed the other user would have know way of knowing unless they hit the “Envair” (enter, yes the scripting is in… spanish?). This of course was not the point of a live chat so I dug through the code (formatted in some strange language to me) to fix the problem.


The code goes towards the end of the code.js document (located at master/js/chat.js), specifically at the end of the UpdateTimer() function.

What the code does is register a submission as if you entered text, but sends a blank set of data, wich tells the script to update without posting. This is very much a hack and should only be used if your on a server that will not allow the automatic refreshing of the script as written.