Image Scaling

[niccol]

All this does is create scaled versions of images on the site (if the image is inserted using zen_image like the product images. It does this the first time that specific size is requested. After that first time it uses the stored version.

It is at a very early stage but if anyone want to give it a go on a development site (NOT A LIVE STORE) then that would be great. It's advantage is that it is a single file :-)

It has limitations at the moment so you may have issues if your server is configured in certain ways and if your images are large. (It only uses GD at the moment)

It is VERY simple and really at this stage is proof of concept rather than a finished article. But if anyone can add some feedback then it might turn into something. There is a read me file in the zip.

Thanks

[DivaVocals]

Scale on demand rather than scale on upload. Interesting... I was talking to a fellow Zenner about this very concept.. He however felt that the image should only DISPLAY and scale on demand.. No image cache/storage at all.. What do you think about this concept?? Is it something you've also been leaning towards??

All this does is create scaled versions of images on the site (if the image is inserted using zen_image like the product images. It does this the first time that specific size is requested. After that first time it uses the stored version.

It is at a very early stage but if anyone want to give it a go on a development site (NOT A LIVE STORE) then that would be great. It's advantage is that it is a single file :-)

It has limitations at the moment so you may have issues if your server is configured in certain ways and if your images are large. (It only uses GD at the moment)

It is VERY simple and really at this stage is proof of concept rather than a finished article. But if anyone can add some feedback then it might turn into something. There is a read me file in the zip.

Thanks

[niccol]

Yes, I remember you mentioned that to me before.

I'd like to see something that did that, I think that if you don't store the image in some way then it would probably be a mistake. It just seems strange not to. I mean, the only disadvantage is that you need the space on the server and to be honest server space is really cheap.

So, if you had a highly specified server that did not have a problem with rescaling images again and again but did not have much disk space then I'd think that the no-caching approach was a good idea. But disk space is much easier to find than good processing on servers in general. (Yes, I know that you can have both but Zen is run on all kinds of shared, slightly dubious servers all over the world )

So, I guess that I see three approaches

1. Create all the image sizes that you need and store them when them the image is first uploaded. That is the other version you have. I kind of ran into a few issues with that for me because I tend to build sites with more than the standard small, medium, large image set.

2. Create a scaled version when it is required by a browser request. And store it in some way. Re-use it when that image is required again.

3. Create a scaled version on-the-fly when required by a browser request. Keep doing that for each browser request and do not store or cache the images.

I thought I would like Option 1 best, but as it is turning out I kind of think that I like option 2 better as it is much more flexible. Option 1 is good because it places the processing overhead on the administrator but it just means that everything is nailed down in a way that I started to find constricting.

The option that this thread is about is option 2.

[DivaVocals]

I think his thought was that it would be stored in a "temporary" cache file.. I REALLY have to find that conversation and post the more interesting points of it for you..

It sounds like your FINAL solution will be Option number 2 as opposed to Option 1 (the one I have), am I correct to assume this??

Yes, I remember you mentioned that to me before.

I'd like to see something that did that, I think that if you don't store the image in some way then it would probably be a mistake. It just seems strange not to. I mean, the only disadvantage is that you need the space on the server and to be honest server space is really cheap.

So, if you had a highly specified server that did not have a problem with rescaling images again and again but did not have much disk space then I'd think that the no-caching approach was a good idea. But disk space is much easier to find than good processing on servers in general. (Yes, I know that you can have both but Zen is run on all kinds of shared, slightly dubious servers all over the world )

So, I guess that I see three approaches

1. Create all the image sizes that you need and store them when them the image is first uploaded. That is the other version you have. I kind of ran into a few issues with that for me because I tend to build sites with more than the standard small, medium, large image set.

2. Create a scaled version when it is required by a browser request. And store it in some way. Re-use it when that image is required again.

3. Create a scaled version on-the-fly when required by a browser request. Keep doing that for each browser request and do not store or cache the images.

I thought I would like Option 1 best, but as it is turning out I kind of think that I like option 2 better as it is much more flexible. Option 1 is good because it places the processing overhead on the administrator but it just means that everything is nailed down in a way that I started to find constricting.

The option that this thread is about is option 2.

[DivaVocals]

Here's the conversation (names changed to protect the innocent):

Fellow Zenner Who Shall Remain Anonymous: IH has so many base issues- I've never installed it once
Little Ol' Me: What issues??
Little Ol' Me: Would love your take on it..
Fellow Zenner Who Shall Remain Anonymous: Non-SEO capatibilty for starters
Fellow Zenner Who Shall Remain Anonymous: No smart resize/crop capability
Little Ol' Me: It's always worked well for me.. Makes it EASY for me to help clients with product images.. Trying to teach them Zen
Little Ol' Me: But it does re-size images.. it always has..
Fellow Zenner Who Shall Remain Anonymous: It's wierd work/don't work issue based on where the image is displayed
Little Ol' Me: It doesn't crop images.. but it does indeed resize them..
Fellow Zenner Who Shall Remain Anonymous: It' resizes, but does not do an intelligent crop
Little Ol' Me: No it never did crop images..
Fellow Zenner Who Shall Remain Anonymous: the huge cache it creates
Fellow Zenner Who Shall Remain Anonymous: and does not manage
Fellow Zenner Who Shall Remain Anonymous: leaving lots of orphaned images
Little Ol' Me: That's true..
Little Ol' Me: and the only way to fix that is to periodically clear the image cache..
Fellow Zenner Who Shall Remain Anonymous: and kills backups because of that
Little Ol' Me: How does it kill backups??
Fellow Zenner Who Shall Remain Anonymous: They become too large and most servers timeout
Little Ol' Me: Ahhhh
Little Ol' Me: I don't include the bmz_cache folder when doing backups..
Little Ol' Me: and I don't transfer the contents of the bmz_cache either when moving sites..
Fellow Zenner Who Shall Remain Anonymous: That's if you do a selective backup rather than a full
Little Ol' Me: Exactly..
Fellow Zenner Who Shall Remain Anonymous: And that's one area I don't want to have to teach a client about
Little Ol' Me: Now that's one thing I don't teach them at all..
Little Ol' Me: Explaining how to backup their sites is one of those areas they just don't seem to "get"..
Fellow Zenner Who Shall Remain Anonymous: precisely- and if they are using IH they get stuck
Little Ol' Me: So I usually setup their backups for them.. after that they just have to run..
Fellow Zenner Who Shall Remain Anonymous: usually because their host has them tied down to storage space
Little Ol' Me: yeah.. if the host allows I usually have the backup results e-mailed to them as a .zip file.. (the site files at lea
Little Ol' Me: the DB backups are done similarly, but seperately.. (e-mailed as a zip if the host allows this)
Little Ol' Me: One Zen Cart community member sent me code to add cropping to IH2, but she also included code to
Little Ol' Me: Tha's poor image management practice, and it shouldn;t be a part of IH2 IMHO
Little Ol' Me: the cropping part would be cool though..
Little Ol' Me: Would love to figure out how to make the cache periodically clean itself automatically or at the VERY LEAST, notify
Fellow Zenner Who Shall Remain Anonymous: I never got the reason behind the cache- If the mod is going to create the image on-the-f
Little Ol' Me: I've been reading Tim's documentation and it kinda makes sense..
Little Ol' Me: The resizing, compression, and image conversion options create a new file, which preserves the original image..
Little Ol' Me: So if the shopowner decides to change any of those options, they do not have to upload a new image again..
Fellow Zenner Who Shall Remain Anonymous: Yes, but there is no need to create the file and store it- You can create it on the fly e
Little Ol' Me: From what if you don;t preserve the original image??
Little Ol' Me: You can't take a JPG make it into a GIF, and then later take that same GIF and turn it back into a JPG..
Fellow Zenner Who Shall Remain Anonymous: But if you wipe the original image- the stored images should also be wiped
Fellow Zenner Who Shall Remain Anonymous: yes you can
Little Ol' Me: I don't disagree..
Little Ol' Me: would lose image quality along the way..
Fellow Zenner Who Shall Remain Anonymous: going from lossy to non-lossy and back again- yes
Little Ol' Me: preserving the original image means you create the new image with the new settings and retain the image quality..
Fellow Zenner Who Shall Remain Anonymous: but that depends on your compression ratio
Little Ol' Me: what's NOT here is the fact that the old image is left behind in the cache..
Little Ol' Me: if you change image settings the mod should create the new image, and remove the old one..
Fellow Zenner Who Shall Remain Anonymous: IH also has an issue of updating when a new image with the same name get's uploaded
Little Ol' Me: No doubt the cache management leaves a LOT to be desired..
Fellow Zenner Who Shall Remain Anonymous: That's why creating the image 'on-the-fly' is the better option
Fellow Zenner Who Shall Remain Anonymous: It's always based on the current base image and it does not tank up l
Little Ol' Me: But again.. I'm not understanding what you would create them from?? Would the shopowner have to
Fellow Zenner Who Shall Remain Anonymous: no
Little Ol' Me: They can't create a new image from an exiting image that's already compressed..
Little Ol' Me: the quality would be awful
Fellow Zenner Who Shall Remain Anonymous: Take a good base image of a decent resolution and just create the offfshoot images from i
Little Ol' Me: Right.. but the original image and the compressed resized image are both being stored then..
Fellow Zenner Who Shall Remain Anonymous: The base image always exists
Fellow Zenner Who Shall Remain Anonymous: and the child images are created from it
Fellow Zenner Who Shall Remain Anonymous: Replace the base image and the child images are changed automatically
Little Ol' Me: okay.. I'm still not clear.. aside from the fact that IH2 doesn't clean up after itself (orphaed
Fellow Zenner Who Shall Remain Anonymous: Only one copy of the image would exist
Fellow Zenner Who Shall Remain Anonymous: so- minimal storage
Little Ol' Me: and where would the original exist??
Fellow Zenner Who Shall Remain Anonymous: all other copies are created as they are called on
Little Ol' Me: the image you used to create this "on the fly" image??
Fellow Zenner Who Shall Remain Anonymous: images/
Little Ol' Me: that's where they are stored now if you use IH2..
Fellow Zenner Who Shall Remain Anonymous: you can add as many different varients of the original image as you want
Fellow Zenner Who Shall Remain Anonymous: each new variant only exists for as long as the person viewing that image is browsing the
Little Ol' Me: but all those variants will be seen as additional images based on how Zen Carts additional image recognition code wo
Fellow Zenner Who Shall Remain Anonymous: exactly- but ZC does not need to know if that image truly exists or not
Little Ol' Me: but that's actually not desireable behavior..
Fellow Zenner Who Shall Remain Anonymous: As for image based SEO- then the root image will do the job
Fellow Zenner Who Shall Remain Anonymous: All ZC needs to know is that if it calls on an image then an image will be served
Fellow Zenner Who Shall Remain Anonymous: In fact it doesn't even need to know that as it does not do an inventory check on images
Little Ol' Me: in your "on the fly" model I would upload one image named daisy.jpg.. The "on the fly" functionality will create the
Fellow Zenner Who Shall Remain Anonymous: even the various SitemapXML mods don't even check that
Fellow Zenner Who Shall Remain Anonymous: yep
Fellow Zenner Who Shall Remain Anonymous: but only when called
Little Ol' Me: But Zen Carts way of recognizing additional images is based on the NAME of the image..
Fellow Zenner Who Shall Remain Anonymous: if someone does not view the medium daisy.jpg then it is never created
Little Ol' Me: and in the example I just sited, the product page will show one image and two additional images for this product..
Fellow Zenner Who Shall Remain Anonymous: ZC only recognises the base image- if jumps thru hoops to get to the large and medium fom
Little Ol' Me: so your approach would modify the way Zen Cart currently identifies additional images???
Fellow Zenner Who Shall Remain Anonymous: no,
Fellow Zenner Who Shall Remain Anonymous: ZC only lists additional images if they exist in the same folder with
Fellow Zenner Who Shall Remain Anonymous: it does not look in the large and medium folders
Fellow Zenner Who Shall Remain Anonymous: these only get called for when someone clicks on an image or if it's required in a listin
Little Ol' Me:_med.JPG, and daisy_lrg.JPGThen I don't get it.. In the example I sited, Zen Cart (without IH2) would display daisy_sm.JPG, daisy_med.JPG,
Little Ol' Me: actually it would show daisy.JPG, daisy_sm.JPG, daisy_med.JPG, and daisy_lrg.JPG as one main image and three additio
Fellow Zenner Who Shall Remain Anonymous: No, with only one base image, it would only display one image
Fellow Zenner Who Shall Remain Anonymous: It would not be aware of the other images because they don't exist
Little Ol' Me: Zen Cart's product image code really doesn't work that way now..
Fellow Zenner Who Shall Remain Anonymous: Sure it does- it just looks in one folder for the images
Fellow Zenner Who Shall Remain Anonymous: images/
Fellow Zenner Who Shall Remain Anonymous: large is put in images/large and medium in images/medium
Little Ol' Me: and if all four of those images are in that folder linked to one product Zen Cart links them all
Fellow Zenner Who Shall Remain Anonymous: the start of the image name. daisy.jpg will link to daisy01.jpg, daisy02.jpg and daisy_gi
Little Ol' Me: doesn't even matter if I have images in the large or medium folders..
Fellow Zenner Who Shall Remain Anonymous: nope
Fellow Zenner Who Shall Remain Anonymous: if they don't have a base image then they are never seen
Little Ol' Me: But what product wouldn't have a base image and then have other images??
Little Ol' Me: How would you have a large product image without a base image??
Fellow Zenner Who Shall Remain Anonymous: Most ZC products out there
Little Ol' Me: how would you have a small product image without a base image??
Fellow Zenner Who Shall Remain Anonymous: your base image can be large- ZC resizes it
Little Ol' Me: Right.. but every image named like my base image would be seen as an additional image..
Fellow Zenner Who Shall Remain Anonymous: yep
Little Ol' Me: I'm not getting how I can have four images with the same base name NOT be seen as additional images..
Little Ol' Me: go back to my daisy example..
Little Ol' Me: HOW does that happen with the way Zen Cart decided how to link additional images to a product..
Fellow Zenner Who Shall Remain Anonymous: But daisy_medium and daisy_small are not addtional images- they are variants
Fellow Zenner Who Shall Remain Anonymous: they get called for other purposes
Little Ol' Me: and Zen Cart willsee them as additional image today.. simply because daisy.JPG is seen as linked to daisy_medium.jpg
Fellow Zenner Who Shall Remain Anonymous: that's why they are in different folders, so they don't get called as additonal
Little Ol' Me: Okay..
Little Ol' Me: That makes sens.. So NOW.. I back to my ORIGINAL question..
Fellow Zenner Who Shall Remain Anonymous: similar named images only get linked in the root folder
Little Ol' Me: so in your mod an additional variant folder for small images would have to exist..
Fellow Zenner Who Shall Remain Anonymous: no
Little Ol' Me: Why??
Fellow Zenner Who Shall Remain Anonymous: just the abilty to reply to a call looking for a small image
Little Ol' Me: where is the small product image??
Little Ol' Me: PHYSICALLY??
Little Ol' Me: or does it even exist??
Fellow Zenner Who Shall Remain Anonymous: it's created when called for
Fellow Zenner Who Shall Remain Anonymous: no
Fellow Zenner Who Shall Remain Anonymous: it is created on the fly when ZC asks for it
Fellow Zenner Who Shall Remain Anonymous: it is not a file on the server
Little Ol' Me: So why create physical files for medium and large images then??
Fellow Zenner Who Shall Remain Anonymous: no need
Little Ol' Me: So ALL images would be created when called for.. Not stored anywhere, and the cheese stands alon
Fellow Zenner Who Shall Remain Anonymous: all you have to do is serve back image data when ZC asks for it- It does not have to phys
Fellow Zenner Who Shall Remain Anonymous: You'd still need an original image to create the copies from
Little Ol' Me:
Little Ol' Me: NOW I get it!!!
Little Ol' Me:
Fellow Zenner Who Shall Remain Anonymous: huzzah!

[niccol]

Thanks Diva.

Some of the lines are cropped but I get the gist of it.

Sure it is possible. But that solution is rescaling repeatedly. Which just seems a waste to me. Once you have rescaled once then I can't see the advantage of not storing it. I guess that is just me thinking that storage space is cheap and believing that it is a good idea to minimise server processing. As am example I have some sites where there is the option to list 100 products per page in the product listing. Image sizes are about 120 by 120. The large images are about 1000 by 1000. So on that page using the 'on the fly' method the server is resizing 100 images. And it is doing it every time the page is loaded. The site I am thinking of is medium busy so that is going to create a lot of work for the server. I am not sure that hosting companies are going to appreciate those images not being cached!


Yeah, probably leaning towards Option 2 because of it's flexibility. Which is pretty much what he is suggesting but in my case I am storing the images.

Yes, caching logic is important. Need to think about how to 'clean-up'. But my thoughts are that the hosting should be large enough to hold every image that is used on the store. So on a fairly static site all the images that are used exist on the server and are just served as they are. I am no expert about server optimisation but it seems to make sense that that is the quickest way to get an image to the page.

[DivaVocals]

Thanks Diva.

Some of the lines are cropped but I get the gist of it.

Yeah. my edits to clean up this chat were a little too enthusiastic it seems..

Sure it is possible. But that solution is rescaling repeatedly. Which just seems a waste to me. Once you have rescaled once then I can't see the advantage of not storing it.

This was my thought as well.. I've seen this kind of solution in apps I have worked on in my day job, but I am not sure what the reasoning/advantage of this method truly is.. The only thing that occurs to me is that these were large scale apps with LOTS of historical music and movie data and storing DECADES worth of CD and DVD artwork might become a storage issue over time. Just a guess of course..

I guess that is just me thinking that storage space is cheap and believing that it is a good idea to minimise server processing. As am example I have some sites where there is the option to list 100 products per page in the product listing. Image sizes are about 120 by 120. The large images are about 1000 by 1000. So on that page using the 'on the fly' method the server is resizing 100 images. And it is doing it every time the page is loaded. The site I am thinking of is medium busy so that is going to create a lot of work for the server. I am not sure that hosting companies are going to appreciate those images not being cached!

Yes for small to medium business this might be a concern.. I think though for enterprise sized apps there are different considerations at play.. This might be what our fellow Zenner was thinking as well.. **shrugs**

Yeah, probably leaning towards Option 2 because of it's flexibility. Which is pretty much what he is suggesting but in my case I am storing the images.

Yes, caching logic is important. Need to think about how to 'clean-up'. But my thoughts are that the hosting should be large enough to hold every image that is used on the store. So on a fairly static site all the images that are used exist on the server and are just served as they are. I am no expert about server optimisation but it seems to make sense that that is the quickest way to get an image to the page.

If images are being resized on the the fly and then stored I assume this is no more or less of a performance hit than how say the current flavor of IH3 works correct??

Finally would you be looking to include some "automated" clean-up options for updating the stored re-sized images if say the base image is updated/replaced?? or did you have something more manual in mind??

[niccol]

Performance hits compared to IH would be about the same I guess. A lot less code so a very small advantage there.

Clean Up.
Hmm, not really sure. The issue here is that there is a danger in any file deletion. (Ha ha - that is an understatement). In this case though I guess we are only talking about deleting scaled images. If a mistake is made there then they just get rescaled.
At the moment I have an admin page that handles additional images and what I am calling 'variants'. A variant is just an alternative version of a scaled image. So if there is a 300 by 200 version of an image stored, you can upload a different version of that file. So, that means that any one of the scaled images can be replaced with an image of your choice. So, kind of like having different small medium and large images but even more flexible.
So, to get to the point - on that admin page I am scanning the directories and putting a warning up if there are scaled images that have not been accessed for more than 24 hours (just an example time) . If 'redundant' files are found then there is an option to delete them.
Obviously this could be run from cron. But I am kind of loathe to go down the cron route as it is a can of worms. Easy but configuring cron is challenging to describe for every server!

The problem with automating if a product image is changed is that another product might be using that image too. I know not likely but possible. Maybe most likely with duplicated products. So, I kind of think it is better to let the system above pick up the old file once it has sat around doing nothing for a while.

[DivaVocals]

I hear what you are saying, but let me throw this out there then..

If multiple products were sharing the same images, I would assume that that this would be intentional on the shopowners part. In this second situation the shopowner would need options if they made changes to thier product images to update the re-sized images. So I would think that deleting and re-generating the images is not an issue.. If there are products which will no longer be sharing images, the shopowner will simply upload the new image to the appropriate product and re-size on the fly would take care of re-sizing and displaying the new image.

The exception would be in the rare instance where the shopowner did not pay attention to how their images were named and thus had products accidentally sharing images. In this second situation the shopowner would want to fix this so that their products display the correct images. Therefore deleting and re-generating the stored re-sized images is not an issue..

If you think about this, in the current flavor of IH3, the clear cache function does just this (not efficiently I admit). It removes all the cached images so that they can be re-genrated... It is suggested that shopowners do this only when they've made significant changes to their existing product images, or when they have deleted products from their shop. (No need to store resized cached images when the product no longer exists) This only affects the stored chached images, the originals are left intact. JMHO, but I think this is important functionality in any new image app..

Clean Up.
Hmm, not really sure. The issue here is that there is a danger in any file deletion. (Ha ha - that is an understatement). In this case though I guess we are only talking about deleting scaled images. If a mistake is made there then they just get rescaled.
At the moment I have an admin page that handles additional images and what I am calling 'variants'. A variant is just an alternative version of a scaled image. So if there is a 300 by 200 version of an image stored, you can upload a different version of that file. So, that means that any one of the scaled images can be replaced with an image of your choice. So, kind of like having different small medium and large images but even more flexible.
So, to get to the point - on that admin page I am scanning the directories and putting a warning up if there are scaled images that have not been accessed for more than 24 hours (just an example time) . If 'redundant' files are found then there is an option to delete them.
Obviously this could be run from cron. But I am kind of loathe to go down the cron route as it is a can of worms. Easy but configuring cron is challenging to describe for every server!

The problem with automating if a product image is changed is that another product might be using that image too. I know not likely but possible. Maybe most likely with duplicated products. So, I kind of think it is better to let the system above pick up the old file once it has sat around doing nothing for a while.

[niccol]

Point taken.

Having the equivalent of the IH clear cache is straight-forward anyway. You just delete everything

I think that my way which is detailed above is a bit nicer than that for two reasons. It only deletes the images that have not been accessed recently which seems sensible. And it alerts is it thinks it needs to be done.

So, both the above options should be iincluded.

Other image tidying up:
Yes I can see this. It would be nice if scaled versions were deleted on:
-- product image change
-- product deletion
What other situations?

Actually, I think this is great but I don't think it is critical. My scanning process is going to pick these files up the next time round anyway. Which will mean that there are only ever scaled versions on the server that are actually being used.

Which leads me to think that cron is the way to go despite the technical issues with getting users to set up a cron job successfullly. Because if you have cron running a scan and clear-up of files that are not being used then you don't actually need to do anything else.