So, following on from here:

http://phpbuilder.com/board/showthread.php?&t=10372650

because we're moving away from that issue.

First, the question was asked as to why I don't want to store them on the file system and here are the reasons:

  1. This site was originally a Ruby on Rails app and I'm converting it. For that reason all images are currently stored in the DB.

  2. I'm linking the images to my articles and I'll need a thumbnail and a normal sized version. By keeping everything in the DB I minimise the chance of the physical files and the DB information getting out of step.

  3. Backing up the site is much easier 🙂

  4. To use the file system will mean CHMODing directories in the public folder which I consider a bit of a security issue. One of my sites had something 'living' on one such directory which disturbed me.

So, for each article I want to take the image, resize it to the maximum size needed for article output and also resize to create a thumbnail for the article's abstract, and then to write these out to the database.

Additionally I would like to be able to take a BMP file entered and convert to a JPG. Actually I'd like to do that with PNG files too. The reason for this is my user is not at all good with images. He doesn't understand the different types, nor how to convert them and he has a lot of work to do on the site anyway. At the moment there are several images he will upload as big PNG files or BMP files particularly that I then have to go through and change afterwards.

My issue with this is that the GD libraries don't seem to be well set up to give out the JPG data in a way I can store on the DB. It seems to only be direct output methods.

So:
- Is there a way to do what I'm doing?
- Am I wrong about the advantages of DB vs. file system?
- If the GD libraries are just not going to work with the DB and will need the filesystem, are there better ways to go about this?

Thanks in advance.

    TheoGB wrote:

    Additionally I would like to be able to take a BMP file entered and convert to a JPG. Actually I'd like to do that with PNG files too.

    That's fairly easy to do. If you can detect which type of image you're working with (e.g. via the file extension, if you can trust it), you can simply use the appropriate imagecreatefrom*() function to open the image file and, when you're done processing it, write it out to JPEG format using the imagejpeg() function.

    TheoGB wrote:

    My issue with this is that the GD libraries don't seem to be well set up to give out the JPG data in a way I can store on the DB.

    Eh... it's not a simple parameter change, but yes, it can be done. More on that below...

    TheoGB wrote:

    - Is there a way to do what I'm doing?

    Yes. It's a bit of a kludge, IMHO, but what you can do is use output buffering (e.g. [man]ob_start/man) before calling imagejpeg() to capture the image data rather than allowing it to be outputted. Then you'd use [man]ob_get_clean/man to retrieve the image data from the buffer (and subsequently clear it, since you don't actually want to output the image at this time) into a variable, which you could then store the value (the binary image data) in your DB.

    TheoGB wrote:

    - Am I wrong about the advantages of DB vs. file system?

    IMHO, yes. You're introducing the overhead of using PHP and a database to retrieve images on every single page load. If you're really worried about the images getting "out of sync" with the DB, you can always store metadata in the DB for each image (e.g. filesize or even a CRC hash) to check this. And as for directory security... it sounds like you're on a shared host, therefore I have a hard time believing you're seriously concerned about security in the first place. :p

    However, "to each his own" as they say.

    TheoGB wrote:

    - If the GD libraries are just not going to work with the DB and will need the filesystem, are there better ways to go about this?

    This would be even more applicable if you were storing the images on the file system alone, but many hosts have ImageMagick installed. This is a third party application that is often used to quickly resize/manipulate images efficiently. It doesn't have the limitations that the PHP implementations of the GD library has, such as requiring large amounts of memory to even open images.

    If you had this tool available to you, and you still wanted to go with your DB approach, you could always use it to process/resize the images, load the new images into PHP (a simple [man]file_get_contents/man, [man]unlink/man the files from the file system, and then store the binary data in the DB.

      Okay, cheers.

      I'll look into those and come back here when I've checked it out.

      I'm familiar with ImageMagick from Ruby on Rails stuff. I'll see if my hosts have it installed.

        Write a Reply...