Question

So here is how we plan on doing it in PHP, but we don’t know if this is advisable. If not, please kindly explain a better alternative.

Let me point out that we would be storing different resolutions of the same image for different devices so that we don’t have to render them in different resolutions on-the-fly which constantly eats up CPU.

So this is how we planning on storing the user pics:

Let’s say we’re storing an image in resolutions of 640px and 320px widths, the user is user 1, and they have one pic. We would store it in:

.../1/640/1.jpg
.../1/320/1.jpg

User 2’s first pic would be stored in:

.../2/640/1.jpg
.../2/320/1.jpg

So if we needed User 2’s 640px pic, we would fetch .../2/640/1.jpg and if we needed User 1’s 320px pic, we would simply fetch .../1/320/1.jpg.

We would then simply store additional pics numerically, so if User 1 uploaded a new pic, it would be stored in:

.../1/640/2.jpg
.../1/320/2.jpg

Their DEFAULT PIC displayed on their profile would ALWAYS be 1.jpg, so if they decided to make their 2nd pic their default pic, we would simply rename all the 2.jpg’s to 1.jpg, and all the 1.jpg’s to 2.jpg’s. Does that make sense?

That way, we can always call their Default pic easly by just pulling in 1.jpg from whatever resolution directory we needed to display.

As more pics are added, we just increment their filename numerically (3.jpg, 4.jpg, etc.) and make corresponding copies in each resolution’s sub-directories (…/640/ and …/320/ for example).

The order of the pics would simply be their numeric order and would be displayed as such, and if the user wanted to change the order of the pics, we would simply rename the files accordingly in EACH resolution’s directory. Yes, a lot of work during each change, but no more work needed until the next change.

What we like about this method is that we do not need to invoke the Database at all since all users will have the same structure based on their User ID.

I hope that all makes sense!

Is this a good method for storing multiple user pics? If not, why not?

Is there a better method? If so, can you please kindly describe it?

Thanks!

Answer 1

This is how I’ve done it in multiple situations:

• Store raw picture somewhere
• Generate image-src, like: src="1234_640x320.png" or src="image.php?id=... (could also include the user id if necessary)
• Route this (mod_rewrite, only needed if you don’t directly use a php file) to a php file, which will check for the actual existence of the resized image (analyzing the original path or using get-variables).
• if the image is not yet resized, resize and store it
• redirect (303) to the new file (next time the image will be resized, so the whole calculation is only done once)

Update:

to clearify:

The idea is to use the request, path or variables, which should in some way include all the needed resize-information, to generate a final storage path.
The path is then checked to actually being a valid image. If not, a resized image will be stored at that location. Implemented correctly, the recalculation only needs to be executed on one request.

The main advantage would be, that it isn’t needed to know all dimensions beforehand. Say for example you’ll suddenly need to serve the image in new dimensions, with this implementation you’ll only need to update the code actually rendering the image-tag.