Image Scaling

[DivaVocals]

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.

Cool.. I'll give this some more thought..

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.

Cron functionality built into the add-on?? -- Yes..

Having to have shopowners who BARELY know how to use their cPanel let alone the intricacies of setting up a cron job, setup a cron job?? and then having to explain it OVER AND OVER AND OVER again to these same kinds of users???? -- **draws in a deep breath**

[niccol]

Well you made me think about this as I drove a friend to the airport.

What about putting a function in application_bottom so it fires at the end of page load?

-- it checks if a clean-up has already happened this session. If so there is no processing overhead because it does nothing. Using a session variable as a flag
-- it checks when the last clean up happened and if that was less that a day ( a week, a month, a whatever ) ago sets the session variable to 'don't bother'. Which is a very minimal overhead.
- if is more than a day ( a week, a month, a whatever ) it does a clean up and then sets the session variable to 'don't bother'. Which is a bit of a larger overhead.

That way one customer a day ( a week, a month, a whatever ) will suffer a slight performance lag at the end of their first page load. And the 'scaled images will never be bloated.

What do you think?

[DivaVocals]

Well you made me think about this as I drove a friend to the airport.

I have that effect on people..

What about putting a function in application_bottom so it fires at the end of page load?

-- it checks if a clean-up has already happened this session. If so there is no processing overhead because it does nothing. Using a session variable as a flag
-- it checks when the last clean up happened and if that was less that a day ( a week, a month, a whatever ) ago sets the session variable to 'don't bother'. Which is a very minimal overhead.
- if is more than a day ( a week, a month, a whatever ) it does a clean up and then sets the session variable to 'don't bother'. Which is a bit of a larger overhead.

If I understand this correctly you are talking about re-size/optimization on demand, and then cleanup on demand as well?? If so I like it!! It's simple, and "idiot proof" as we like to say at my office.. K.I.S.S. software (Keep it simple stupid )

That way one customer a day ( a week, a month, a whatever ) will suffer a slight performance lag at the end of their first page load. And the 'scaled images will never be bloated.

What do you think?

Clarify a few things for me though..

• I assume the frequency of when the cleanup check is performed is an admin configurable option?? (If not it probably should be..)
• When you talk about the one customer a day suffering a slight performance lag while this check takes place, are you saying that this one customer viewing one product will trigger the re-generation of ALL product images or just the product they are currently viewing??

[niccol]

Well, yes, I was kind of thinking of letting the user choose either or both methods. The requirements are quite different on a store that has three visitors a month and a store with lots of vistors and frequent catalog changes.

Well, what I am saying is that the scaled images will be scanned to see if one has not been accessed for more than 'the period of time'. Which would suggest that they are not actually needed. Only those redundant images would be deleted. Any images that have been used in the last 'period of time' would not be touched.

If the function was fired in application_bottom it would fire on the first page load of each user. Most of the time it would do nothing. Once a 'period of time' it would delete the redundant images but not create any images. So, it is fast.

I did think of limitting the number of images that an individual page load deleted. So, a individual page load would delete only ten images for instance and leave the rest for the time being. Not sure about that. As I am only talking about deleting images that are not actually being used, I can't see that there would be that many. ( famous last words ) I mean we are basically talking about orphaned images. I guess if you had uploaded new images for a whole chunk of the catalog then there might be a few...

I am not sure that the user would even notice if it fired at the bottom of the page once the page has loaded. Possibly, one could do it in an ajaxy way anyway so it really didn't effect the page at all.

So there are a couple of admin settings:
-- frequency of clean up
-- period of time after which a file is considered redundant
-- type of clean up manual, automatic or both.

[DivaVocals]

Sounds awesome.. Can't wait to see the next version of this..

Well, yes, I was kind of thinking of letting the user choose either or both methods. The requirements are quite different on a store that has three visitors a month and a store with lots of vistors and frequent catalog changes.

Well, what I am saying is that the scaled images will be scanned to see if one has not been accessed for more than 'the period of time'. Which would suggest that they are not actually needed. Only those redundant images would be deleted. Any images that have been used in the last 'period of time' would not be touched.

If the function was fired in application_bottom it would fire on the first page load of each user. Most of the time it would do nothing. Once a 'period of time' it would delete the redundant images but not create any images. So, it is fast.

I did think of limitting the number of images that an individual page load deleted. So, a individual page load would delete only ten images for instance and leave the rest for the time being. Not sure about that. As I am only talking about deleting images that are not actually being used, I can't see that there would be that many. ( famous last words ) I mean we are basically talking about orphaned images. I guess if you had uploaded new images for a whole chunk of the catalog then there might be a few...

I am not sure that the user would even notice if it fired at the bottom of the page once the page has loaded. Possibly, one could do it in an ajaxy way anyway so it really didn't effect the page at all.

So there are a couple of admin settings:
-- frequency of clean up
-- period of time after which a file is considered redundant
-- type of clean up manual, automatic or both.

[nigelt74]

Ok, Had a play, seems good

I personally would like some sort of subcategories system (like IH uses with MD5 named subfolders in the BMZ_cache) in the scaled folder, simply because the folder will fill fast, I have on my test site 10 product images all in the root images folder, when i check the scaled folder there are 50 images in there, as i have 5 different image sizes set in my images settings, now i have customers who have thousands of images in the base image directory, won't the current system mean that there is 5 times that amount in the scaled folder.

Definitely keep away from cron-jobs it is absolutely nightmarish trying to explain them to people, infact it ends up being a support issue in its own right.

Not sure on the automated deletion scan being on the customers side, or at least the impact being felt on the customers side, would personally prefer a reminder come up like the "clear admin activity log" on the admin side

But other than that it doesn't seem to have too much of an impact on performance, should be fairly idiot proof to install.

[niccol]

thanks Nigel.

yeah, last night I changed the system so at least it replicates the directory structure existing on the images. so if the root image is images/products/image.png the scaled version is stored in images/scaled/products/image.png.

I know that this doesn't completely address what you are saying. Particularly as most users just put all the images in the main directory.

I am interested in why you think that 'indexing' the scaled images is a good idea. Obviously there is a performance issue in searching 5000 files for a match. But is there something else I am missing?

Well, yes, I have some apprehension about putting the clean-up overhead on the client-side. I'd certainly put it as an option rather than a default. The thing is that it is a 'scan and delete' of orphaned files rather than a re-create scenario so would be relatively quick. And happening for a single page load once a week doesn't seem like a massive penalty particularly if it happens after page load.

But I do understand what you are saying. When I started thinking about this, my point was that all processing overheads should be on the admin end. So, I thought that 'scale on upload' was the way to go. I kind of got tied up in trying to use the existing medium and large formats of Zen and that meant that there was a whole loss of flexibility. This way works better because any zen_image request creates a scaled version so you can have 10 different scaled sizes. I do a lot of work with zoom effects and slideshows and other jQuery nonsense so it is good to be able to produce a scaled version of the exact size you want.

Which is all to say that i wanted to keep processing overhead on the admin side. But once you have compromised that to put the actual scaling overhead to client side then putting the clean up on client side is less of a kick in the teeth.

Should have version 2 up in the next couple of days.

It will have -
-- a similar scaling feature
-- an admin page for additional images and variants. A variant is just an alternative version of a scaled image. this is very flexible and I like it!
-- a first shot at the two clean up methods

It would be lovely if you could have another play.

Yes, I am trying to keep it as simple for the user, both in install and in use, as is humanly possible. I have read the IH support thread and only have huge admiration for the people who have taken that on.

Just as a last thought.
I think that I won't bother with some of the features in IH. For me it makes sense to do some of the issues in a separate mod. This definitely applies to front end features like the hover effects. But in this case what I am thinking of is building a upload modifier that takes care of :

• watermarking
• limiting maximum size
• adding sharpness
• renaming

Basically because I do think that those actions make more sense on upload.

In the past I have tried renaming uploads with a sanitised version of the product name. It seems to work well but should obviously be an option rather than a default.

Thanks again

[DivaVocals]

thanks Nigel.

Yes I'm glad nigel joined the party too..

yeah, last night I changed the system so at least it replicates the directory structure existing on the images. so if the root image is images/products/image.png the scaled version is stored in images/scaled/products/image.png.

I know that this doesn't completely address what you are saying. Particularly as most users just put all the images in the main directory.

I am interested in why you think that 'indexing' the scaled images is a good idea. Obviously there is a performance issue in searching 5000 files for a match. But is there something else I am missing?

Well, yes, I have some apprehension about putting the clean-up overhead on the client-side. I'd certainly put it as an option rather than a default. The thing is that it is a 'scan and delete' of orphaned files rather than a re-create scenario so would be relatively quick. And happening for a single page load once a week doesn't seem like a massive penalty particularly if it happens after page load.

But I do understand what you are saying. When I started thinking about this, my point was that all processing overheads should be on the admin end. So, I thought that 'scale on upload' was the way to go. I kind of got tied up in trying to use the existing medium and large formats of Zen and that meant that there was a whole loss of flexibility. This way works better because any zen_image request creates a scaled version so you can have 10 different scaled sizes. I do a lot of work with zoom effects and slideshows and other jQuery nonsense so it is good to be able to produce a scaled version of the exact size you want.

Which is all to say that i wanted to keep processing overhead on the admin side. But once you have compromised that to put the actual scaling overhead to client side then putting the clean up on client side is less of a kick in the teeth.

Should have version 2 up in the next couple of days.

It will have -
-- a similar scaling feature
-- an admin page for additional images and variants. A variant is just an alternative version of a scaled image. this is very flexible and I like it!
-- a first shot at the two clean up methods

It would be lovely if you could have another play.

Yes, I am trying to keep it as simple for the user, both in install and in use, as is humanly possible. I have read the IH support thread and only have huge admiration for the people who have taken that on.

Just as a last thought.
I think that I won't bother with some of the features in IH. For me it makes sense to do some of the issues in a separate mod. This definitely applies to front end features like the hover effects. But in this case what I am thinking of is building a upload modifier that takes care of :

• watermarking
• limiting maximum size
• adding sharpness
• renaming

Basically because I do think that those actions make more sense on upload.

I say ALL the time that the hover feature is a NICE to have, but NO ONE shoud be installing IH3 JUST for that feature.. So I personally wouldn't be sad with it not part of the mod.. I like the idea for the watermarking etc.. as I thought that those really were normal image management features where as the image hovering effect is not an image management function at all. Gallery3 for example has watermarking options for it's photo gallery application. (but no image hovering)

Can't wait to test the next version of this..

In the past I have tried renaming uploads with a sanitised version of the product name. It seems to work well but should obviously be an option rather than a default.

Thanks again

This caught my eye and I have a functionality suggestion.. What if the renaming with a "with a sanitised version of the product name" worked something like how Ceon URI Mapping generates product/category URIs?? You could include admin configurable options to cover things like what to replace the spaces in the product names with (dashes, underscores, etc). This would take care of SEO issues people complain about with IH3.. Of course people will have to take care not to have duplicate product names (they have to do this as well with the Ceon mod) and if you want to make this "idiot proof" your renaming function could check for duplicate names and inform the user on-screen of a duplicate name situation.

[niccol]

I like watermarking too. But my point is that it could happen once on upload. And never again. ( Hmmm, existing stores may be a problem?)

Likewise I think that renaming is a nice idea both for practicality because you can solve some of the character set issues and because it makes images easy to recognise. And may or may not help with SEO. But again should happen once on upload.

Likewise sharpen or unsharp mask. Which some carts do very well at the moment.

Likewise limiting the biggest size which would basically rescale before the image is saved so that no images on the server were larger than ( a configurable ) dimension. Which I think again would be a nice feature. Partly for functionality and server space and partly because the large images would be more consistent in format.

But all of these might happen on upload. I guess what I am saying is that in my mind I am separating the actions to do with scaling and serving images from the actions to do with uploading the image.

All obviously configurable in admin.

Image renaming: yes that would be good. When I get there I'll start with a 'hard' rename that puts it into lowercase and then removes odd characters. From there we can have a think about what other filters might be a good idea.

[niccol]

Re-reading.

My solution to duplicate names is just not to allow it. Previously I have versioned images by putting an extra string on the end. So image.png becomes image_v01.png and doesn't overwrite. With Zen there is just the added complication of making sure that that image does not appear as an additional image. Putting the string at the front is an obvious solution but not all that elegant!