Re: Weird Image Problem
| From: | Kristen G. Thorson | Date: | Thu, 30 Jun 2005 21:05:22 +0000 |
| Subject: | Re: Weird Image Problem | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-217910@lists.php.net to get a copy of this message | ||
Richard Lynch wrote:
On Wed, June 29, 2005 3:30 pm, Shane Little said:MySQL blobs are actually limited to 64K. I think a MEDIUMBLOB holds about 16 MB if you're dead-set on storing the image in the database. You might want to check that your max_allowed_packets size is large enough. You can find that by querying SHOW VARIABLES LIKE 'max_allowed_packet'; I just double-checked the manual. It does say that this needs to be set to the largest blob. kgtI'm bin2hex'ing images from an upload script and inserting into a mysql blob field. The php script that re-packs the hex data back to binary, does the createimagefromstring() and streams the image to the browser is generating a corrupted image... i.e. The image looks fine until part-way down... then... no more image; just a gray background where the rest of the image should be. Seems to happen on image any larger than 30 or so kilobytes. Anybody working the the php image libraries seen this before?Storing images inside MySQL is almost always a Bad Idea in the first place... I'll assume you know that, and have good reason to not use the super-fast, custom-optimized large-data software specifically designed to handle your images. * First, check that MySQL blob fields are not limited to 32K somehow. I suspect that they are. Next, one has to wonder why use bin2hex? Yes, it should generate only 0-9a-f characters, which are all valid for MySQL, but surely that is not the best way to do this... I don't store images in MySQL, so don't KNOW what is the best way, but I'm putting money down right now that bin2hex ain't the best way. * the super-fast, custom-optimized large-data software specifically designed to handle your images is known as... The File System. :-)