Am I doing too many resizes?

[eluser]KeyStroke[/eluser]
Hi,

I currently have a web application where users upload images. When a single image is uploaded, 3 resizes get performed on it (which means it end up having 4 versions):

- Thumbnail version
- A Preview version that's a bit bigger than the thumbnail one.
- a version that is as big as the site's layout
- the original version

At this point, I think I'm just doing too many resizes. It works fine now, but I'm not sure how that's gonna work under pressure.

As for the code I'm using, it's similar to the ones here: http://ellislab.com/forums/viewthread/85727/#477678

If I'm doing it wrong (theoretically), is there a better way to do it so I can have different sizes for images in my site?

[eluser]rogierb[/eluser]
I don't think that's to many;-)

Just start with the biggest one and work your way down, using the newly created image as the source for the next. Not the best solution but it saves time and a huge amount of memory, especially when resizing jpg.

Make sure you have enough memory. A 2MB jpg can easily use up to 500mb of memory on 1 resize depending on compression rate

Just my 2 cents.

[eluser]KeyStroke[/eluser]
Thanks rogierb.

Two questions regarding your reply though:
1. Why would I resize from biggest to smallest? does it make a difference?

2. If a single resize is using 500 mb of memory, does that mean each concurrent connection will use an additional 500 mb of memory? because that would be memory I can't afford !

[eluser]quexal[/eluser]
[quote author="KeyStroke" date="1225834024"]
1. Why would I resize from biggest to smallest? does it make a difference?
[/quote]

The smaller the JPEG you are resizing, the less amount of memory it will take to resize it.

For instance, if I had an 1600x1200 JPEG @ 300dpi and wanted to resize down to 800x600 @72dpi it would take quite a bit of memory (>100mb), wheras, if I then resize that 800x600 @72dpi JPEG and resize it down to 640x480@72dpi it will use less than 5mb of memory. Actual amount of memory use depends on a couple of other factors, but on my dev system using GD and some test-JPEGs those were my results.
Thus, if you only resize down from previously resized images, you will use less memory, and the resizes will go faster.

[quote author="KeyStroke" date="1225834024"]
2. If a single resize is using 500 mb of memory, does that mean each concurrent connection will use an additional 500 mb of memory? because that would be memory I can't afford
[/quote]

This is true.
The easiest way I've found to get around it is to use a cron-job to process the images after-the fact. I put my uploaded images into a specific (hidden) directory, and the cron-job goes off every minute running a PHP script that looks at the contents of the upload directory and resizes all of the images that sit in the directory, moving them to their final destinations (overwriting placeholder images) upon resizing.

So, when a user uploads an image, the following happens:

- The upload script creates the multiple placeholder files in the correct locations (JPEGs that say "Processing image... please wait")

- The upload script copies the uploaded file to a hidden directory.

- Within a minute the cron-job PHP script goes off it sequentially runs through the images in the directory, resizing all of them, and moving the resized images over to the correct locations, overwriting the placeholder images.

This has solved the many running-out-of-memory issues that I was having when multiple people began uploading images.

- Also, FYI resizing from 300dpi (most cameras output 300dpi images) down to 72dpi (screen resolution) takes ALOT more memory than resizing a 72dpi image. ~228 times more memory is used when resizing a 300dpi image down to a 72dpi image, than resizing a 72dpi image.

Hope this helps,
Matt G.

[eluser]JoostV[/eluser]
I used to get memory exhaustion errors on resizing images over, say, 600K with GD. Never had that problem since I started using ImageMagick. It resizes 10-5MB images, no sweat. Seems a lot more efficient than GD.

[eluser]quexal[/eluser]
I agree... ImageMagick is much more memory efficient for resizing large images.

[eluser]KeyStroke[/eluser]
Thanks guys.

So if I want to use ImageMagick instead of GD2, shall I just change the '$config['image_library']' variable, or is there any extra work involved?

[eluser]fesweb[/eluser]

Matt G.
- Also, FYI resizing from 300dpi (most cameras output 300dpi images) down to 72dpi (screen resolution) takes ALOT more memory than resizing a 72dpi image. ~228 times more memory is used when resizing a 300dpi image down to a 72dpi image, than resizing a 72dpi image.

Is this true?

I've always gone on the theory that pixels is pixels. A 900px x 600px image at 300 dpi should be the exact same size as a 900px x 600px image at 150dpi or 72dpi. When not printing an image, dpi essentially seems to be meta information.

Honest question: is there an actual, verifiable, difference in processing time?

Matt G. (also)

[eluser]Phil Norton[/eluser]
[quote author="fesweb" date="1226129595"]

Matt G.
- Also, FYI resizing from 300dpi (most cameras output 300dpi images) down to 72dpi (screen resolution) takes ALOT more memory than resizing a 72dpi image. ~228 times more memory is used when resizing a 300dpi image down to a 72dpi image, than resizing a 72dpi image.

Is this true?

I've always gone on the theory that pixels is pixels. A 900px x 600px image at 300 dpi should be the exact same size as a 900px x 600px image at 150dpi or 72dpi. When not printing an image, dpi essentially seems to be meta information.
[/quote]

You're correct. DPI is only useful for print (hence the use of "inch"). It's all about the number of pixels, not the resolution.

[eluser]El EmiZ[/eluser]
[quote author="fesweb" date="1226129595"]Honest question: is there an actual, verifiable, difference in processing time?[/quote]

It's common sense, Matt. Processing 2,359,296 units of data (1024x768x24bit) it's not going to take the same processing power and memory using than processing 921,600 units of data (640x480x24bit)...

Greetz