Image handler vs upcoming Zen 1.5

niccol:

Hmmm, I think we kind of have gotten sidetracked onto whether IH is good or not. It has been used by thousands of shops so it obviously has something going for it.

@Nigel - great if you sort out the GET issues :-) I had a look and it was one of those things that just felt it was going to eat my time. So big respect for you.

To me the choice is between the complexity of IH or making a change to a single file to allow resize on upload. Taking a bit of step back from the forest in order to see the trees, I think I will go that route. What meaningful does IH offer me that 'resize on upload' doesn't?

I can add options for watermarking and unsharp mask.

So, I guess the answer is that IH provides nice additional image handling but that can be built as a separate admin page the way it is in IH.

Just my thoughts. And as always I think that there is room for different approaches to the challenge. One of the sad things is that two approaches can not be run at the same time because they both will want to hook into handle_image()....

Why not use Image Manager 1.8 as your base?

-It is already 1.5 compliant.
-Resizes uploaded main and additional image to small, medium and large.
-Applies Watermarks.

Fewer files, easy to install, even easier to upgrade and remove.

It lacks automation of image resizing on upload, sadly a manual process. Also the ability to have different watermarks for different image sizes are missing, but other than that, I believe it does what you ask for.

One nice feature of Image Manager by Boudewijn Sjouke is that it saves your original image file in a separate folder on resizing. I have found that to be very handy!

Oh and the way it keeps your original images name is great for SEO of images. While I do not place 100% of faith in Google Analytic Reports, its says I get 10% of traffic direct from google images on my site. Competitors no doubt trying to steal my product images, but it has resulted in a major direct competitor becoming an invoice client for some of the products I import from Italy that I have a licence for and they cannot get. :D

niccol:

Hmmm, I think we kind of have gotten sidetracked onto whether IH is good or not. It has been used by thousands of shops so it obviously has something going for it.

@Nigel - great if you sort out the GET issues :-) I had a look and it was one of those things that just felt it was going to eat my time. So big respect for you.

To me the choice is between the complexity of IH or making a change to a single file to allow resize on upload. Taking a bit of step back from the forest in order to see the trees, I think I will go that route. What meaningful does IH offer me that 'resize on upload' doesn't?

I can add options for watermarking and unsharp mask.

So, I guess the answer is that IH provides nice additional image handling but that can be built as a separate admin page the way it is in IH.

Just my thoughts. And as always I think that there is room for different approaches to the challenge. One of the sad things is that two approaches can not be run at the same time because they both will want to hook into handle_image()....

Interesting discussion.. As I stated earlier, I had a similar discussion with a fellow forum member. We were discussing ideas for an improvement to IH3. This would include all of the most useful features while eliminating the need for the image cache folders. His idea was to display optimized and re-sized images on the fly as the page is called. This would eliminate the need for the image cache folders, browser re-sizing and like IH3 still retain the original images.

I look forward to seeing what you come up with (provided you share it with the community of course..:smile:)

Just install a Jquery Handler in the main install

Well so far I have working:

-- resize on upload for products. well, actually it creates the versions between preview and update but that seem fine to me.
-- a handle_image() function to deal with the new files
-- I am using a small folder as well because I always thought having the small images in the main directory was a bit counter intuitive but maybe that was just me. Which means that you can keep the originals in the main directory or delete them after upload depending on a setting in admin.
-- admin configurations for what I need
-- an admin page that bulk resizes in one go for rebuilding the image versions if you change the image sizes used in the store - either from the large images or the originals, depending on what you want to do.

Still working on additional images.

So, so far so good and pretty simple so far. Half a dozen or so files and just one overwrite. And the overwrite is just a couple of added lines. Although having said that I am working with GD only rather than imagemagick and I am limiting myself to jpg and png. Although changing those two limitations is really no big deal. I just don't need to at the moment.

Just install a Jquery Handler in the main install
how would that effect the size of the images served to the page? the aim of imageHandler is to reduce the file size to the minimum required.

His idea was to display optimized and re-sized images on the fly as the page is called. This would eliminate the need for the image cache folders, browser re-sizing and like IH3 still retain the original images.

yeah, for sure there are interesting ways to do it. and many ways to skin a cat. my argument would always be that re-sizing once is always better than re-sizing many times (which surely would happen if you don't cache the results) and that the best time to do that resize is when the image is uploaded for the first time. that just kind of seems the most efficient way to do it in my head. but who knows....

niccol:

my argument would always be that re-sizing once is always better than re-sizing many times (which surely would happen if you don't cache the results)This was my initial response as well.. Except the way it was explained to me is that the image is not really being resized many times at all. I need to find our discussion thread and post up some of what he was saying.. Remembering off the top of my head while on pain meds is not working..:laugh:

Hmmm, well I'd be interested in that. Seems to me that if you do not store the image in some way it is going to need to be rescaled again next time. So, for example, on one of the stores that I work on where they display 100 products at a time in a grid for the product listing page and their large images are large, each one is going to have to be rescaled on the fly each time that page is served.

But maybe I am missing something...

As I say I'd be interested in that previous conversation if you can find it.

niccol:

Hmmm, well I'd be interested in that. Seems to me that if you do not store the image in some way it is going to need to be rescaled again next time. So, for example, on one of the stores that I work on where they display 100 products at a time in a grid for the product listing page and their large images are large, each one is going to have to be rescaled on the fly each time that page is served.

But maybe I am missing something...

As I say I'd be interested in that previous conversation if you can find it.

I was faced with a similar problem of a client with a large (4000+) inventory - all with images - that changes frequently. Having IH2 or anything else handle that many images on the fly didn't seam practical.
So I wrote a small image processing module that I could hang off the back of Easypopulate.
The client uploads the images in bulk (ftp) and then presses the process button. The original image is given a watermark and saved in the large folder, then this image is resized to medium and thumb sizes (and centered on a square white b/ground - this saves having to faff about trying to vertical and horizontal align the image display in all browsers) and saved to the appropriate folders. There is an option to delete or not the original image. Works a charm.

@David,

yes, that makes sense to me. it basically does what my 'rebuild' function does.

can't make my mind up about padding the images so that the image is in the center. I think that in some situations this obviously works best as you have described. In others not so great. I don't want to pad the 'large' version for sure because of using it in a lightbox or zoom. And for zooms you want all the images to be the same so that would mean that you don't pad any of them.

Pros and cons.

Which just goes to show it is easier to build a module for a single store than build a 'one size fits all' module to release as a module. Which is a reason why some people like myself do not release all this kind of stuff to the 'community'. Making things work for every situation and every store is hard work! Once again respect for the Zen developers for doing this with the core.

@niccol

What I did for getting images centered was to get the size of the area you want the image in, then get the size of the image.

Subtract the image size from the area size and divide what comes out by two.

Add the result (round down if needed) as margin to the top and bottom of the image.

You could do something similar for centered horizontally, if needed.

Well, centering at the browser end is very possible as you say. I tend to use css to center horizontally and javascript to center vertically, but that is just the way I roll and I almost always have jQuery running on the page anyway. But I am more than aware that there are all kinds of ways of doing it.

The question David and I were talking about is whether when the image is resized you want to add 'padding' or 'margins' to the image itself to make the scaled versions a completely uniform size. Basically that means that the scaled image already has the margins incorporated in it. This is not very technically challenging during the resize process and so is tempting.

The problem is that in jpgs for instance you need to decide what colour the background should be. On a white background site you might end up with a image that contained two stripes of white down either side of the original image to make it up to the required size. This would work fine against the white background of the site.

But if you use the image in some kind of on-page effect, like an image zoom, then the effect is going to apply to all the image including the 'padding' . So, in the case of an image zoom on an image with white 'padding' there is going to be a point when you are simply zooming in on the white padding. Which is kind of a problem.

niccol:

@David,
Which just goes to show it is easier to build a module for a single store than build a 'one size fits all' module to release as a module. Which is a reason why some people like myself do not release all this kind of stuff to the 'community'. Making things work for every situation and every store is hard work! Once again respect for the Zen developers for doing this with the core.

How true - like you I've often thought about making something I've done for a particular store into a module for all to use, but to cover all the bases is just sooo much work. So kudos to all who have taken the trouble and helped make Zen what it is today

@niccol

Sorry, I didn't make myself clear, I use php to do what I described, as you never know what's turned off or on, capability-wise, on the browser end, so this is all precalculated before the browser gets its hands on it.

This is sort of a per case (page type, like product listing, special offer pages, etc) basis though, since otherwise you don't know how large the space where the image is going to go will be.

For me, I wouldn't pre-edit the images with whitespace, for the exact reasons you've written down.

You could always just make it an option, for people who do want it that way, or for other cases and for people with space to spare, both ways.

As you said, it's easier to make a per-site solution. When it's a broad tool you have to cater for everyone and all possibilities of usage ;)

@Diavire

Oh I see what you are saying. Sometimes it takes a bit of extra help for it to sink in :-) Apologies!

Hmmm, that is kind of interesting too. I think that the 'per case' solution as you call it wouldn't necessarily suit me. But I wonder if that approach could be used in zen_image() to add in-line styling to the image (which then of course would need to be display:block) . You'd just add margins so that the resultant box was the same size exactly as the medium image size ( for example).

Obviously this takes a bit more processing because you need to find the actual image size so perhaps purists would object.

@David
Yes, exactly. Kudos to everyone who takes the time to turn a solution for their store into a module for everyone. Kudos to the developers for making a platform that allows so many options.