Image Scaling

niccol:

Hmm, something to look at. It doesn't look to hard to implement in general.

Still, like the concept of scaling them on upload better. That way you are not storing huge images on the server that are never used.
But Zen Cart already has settings which supports limiting the size of file uploads in a configuration setting most folks don't usually look at (and therefore simply accept the default values):
Configuration > Maximum Values
**
Maximum File Upload Size** (Default setting: 2048000KB)

niccol:

I could easily code it so that if a large version was requested it served a version that was limited to max dimensions that were specified in admin.

That is probably the way to go, right? Even if it means saving an additional big version of the image on the server.It's similar to how Image Handler works this out. The large image size is a new configuration setting IH3 adds to the image configuration settings.. Especially since the size of the original image upload can be limited in the store configuration settings..

i think niccols idea is better, resize the large images on upload rather than enforce the Maximum File Upload Size,

bn

bn17311:

i think niccols idea is better, resize the large images on upload rather than enforce the Maximum File Upload Size,

bnYou've missed my point.. Niccol can still code her application do scaling on upload for the large images based on an admin configurable setting if she wishes.. (this is afterall what we were speaking of..) However, my point is that this can be done while retaining the original image. If I understand how the Image Scaler works currently, scaling on upload for ONLY the large images is different than the way the scaled small and medium images are currently generated. (I believe small and medium images are scaled "on demand" when the product page is accessed).

What niccol seems to be leaning towards is scaling the large image on upload and REPLACING the original image with this scaled large image. The question is whether it's a good idea to replace the ORIGINAL uploaded image or REPLACE it with the scaled large image.. Right now Image Scaler doesn't appear to do ANYTHING with the original images when creating the small and medium scaled images.

Her concern seems to be referring to a shopowner uploading an image which may have been too large to begin with being stored in the images folder (if the originals are left in place) even if only the scaled small, medium, and large images are what is served up on the various product and category pages.

I was pointing out that Zen Cart already has BUILT IN functions to deal with this precise situation. It adds some level of insurance that overly large images are not uploaded to the site to begin with. It would NOT be a good idea to "code around" the built in functionality. Better to work WITH built in functionality.. (Hence the reason she modified Image Scaler to now support null or "0" values in the image size settings.. It now works WITH built in Zen Cart functionality)

I personally do not think it's a good idea to "remove" the original image (which scaling on upload for large images will in effect do). Better to generate scaled images based on admin settings and leave the original image alone.

I understand niccols concern, but I think the built in Zen Cart functionality to prevent overly gigantic images from being uploaded to begin with is sufficient protection from foolish behavior. It gives shopowners GREATER flexibility, not LESS if their original images are retained. I say this from experience.. One frequently asked question in the IH3 support thread is surrounding concerns that the original images are not lost in the compression and re-sizing routines..

Plus as niccol pointed out earlier in this thread, disk space is cheap.. So what's the REAL concern/harm with leaving the original image in place and simply generating a scaled large image based on admin settings when the page is accessed in the SAME manner that small and medium images are currently generated??

Found a typo.. so let me clarify my earlier statement:smile:

DivaVocals:

What niccol seems to be leaning towards is scaling the large image on upload and REPLACING the original image with this scaled large image. The question is whether it's a good idea to RETAIN the original uploaded image or REPLACE it with the scaled large image.. Right now Image Scaler doesn't appear to do ANYTHING with the original images when creating the small and medium scaled images.

bn17311:

rather than enforce the Maximum File Upload SizeOne last thought on this.. regardless of what niccol does with Image Scaler, this is enforced for ALL file uploads.. It's part of Zen Cart's built in administration.. Coding around it for JUST images is IMHO a bad idea.. It means you will potentially have an add-on that works differently than Zen Carts built in function..

i maybe dived out with reply before reading properly, i thought you meant restrict the image being uploaded to the max size allowed, ie if its going to 700 wide not to allow images larger than this,
the way you are talking about is what i mean, let user upload image at whatever size they like, obviously restricted by the Maximum File Upload Size (i didnt know it existed) which would only apply on massive images anyway, then niccol image scaler would make a scaled image for large, i always want original kept, this means if i decide to change my image sizes it will recreate scaled images again form original,

bn

Yet another tweak to the settings:) What if there were a user global choice of resizing the original or keeping the original and making a scaled large image? I know total flexibility can cause too many places for things to go wrong and confuse users, but would this be a valuable (and practical) option?

bn17311:

i maybe dived out with reply before reading properly, i thought you meant restrict the image being uploaded to the max size allowed, ie if its going to 700 wide not to allow images larger than this,
the way you are talking about is what i mean, let user upload image at whatever size they like, obviously restricted by the Maximum File Upload Size (i didnt know it existed) which would only apply on massive images anyway, then niccol image scaler would make a scaled image for large, i always want original kept, this means if i decide to change my image sizes it will recreate scaled images again form original,

bnClose but not quite what I meant..:smile:

Image Scaler needs to add an admin setting for the dimensions of the large image. The mod would then generate the scaled large images based on these settings. (Similar to how large images are rendered in Image Handler)

The original image is retained and because Zen Cart has built in settings in the configuration menu to restrict the file size of uploads, there's adequate options in place to ensure that the original images stored do not take up an excessive amount of storage space -- UNLESS the shopowner chooses to configure their store to allow for really large file upload sizes.

This way it's always within the shopowners discretion how to configure their shop, scaled large, medium and small images are created, and the original uncompressed images are retained (but not used for display)..

gjh42:

Yet another tweak to the settings:) What if there were a user global choice of resizing the original or keeping the original and making a scaled large image? I know total flexibility can cause too many places for things to go wrong and confuse users, but would this be a valuable (and practical) option?I started to just agree with this, then I had a thought..

The only issue I see with this is serving up a resized version of the original image as the large image is that it seems to undermine the intended purpose of this mod (image optimization). If the large image is just resized, but not scaled, isn't this counter to the purpose of this mod??

ETA: Unless I misunderstood and what you mean giving shopowners the choice of:
A.) keeping a re-sized/OPTIMIZED version

or

B.) keeping both the original AND creating a re-sized/OPTIMIZED large version

I think that what will work best is to have a 'maximum served size' in Image Scaler. That way the original is kept but the large images are a consistent size.

Then in the Upload Modifier module that exists only in my head at the moment, there is the feature for people to limit the size of the originals. Which in combination with Image Scaler is kind of like a 'don't keep the original' setting.

That seems to cover every angle, doesn't it?

niccol:

I think that what will work best is to have a 'maximum served size' in Image Scaler. That way the original is kept but the large images are a consistent size.

Then in the Upload Modifier module that exists only in my head at the moment,** there is the feature for people to limit the size of the originals.** Which in combination with Image Scaler is kind of like a 'don't keep the original' setting.

That seems to cover every angle, doesn't it?
Are you talking about file size or dimensions?? Because again Zen Cart has built in configuration settings for the former..

ETA: Unless I misunderstood and what you mean giving shopowners the choice of:Yes, that's what I meant. And it appears to be addressed sufficiently by Nick's latest post. The file size vs. dimensions is grounds for further discussion.

gjh42:

Yes, that's what I meant. And it appears to be addressed sufficiently by Nick's latest post. The file size vs. dimensions is grounds for further discussion.I thought so.. After I re-read it I realized WHO I was questioning, and quickly realized the err of my post..:laugh::laugh::laugh:

On the verge of posting the next version but have a few questions:

1. Additional Images.
   I believe it is correct that the additional image needs to be the same type/extension as the main image. What do you think is the best way of handling that? At the moment the additional image uploader saves the image with the correct image extension (not necessarily its own original extension) So basically the type is changed to match the main image. Is that the right way of going or would it be better to alert the user that the types need to be the same which is kind of more in keeping with the Zen standard?

2. Further to that.
   I am working on the 'replace' the original main image function that was suggested. Here the problem is the additional images again. I am renaming them so that they still appear as additional images after the replacement. But, if the new main image is a different type should I look at changing the type of the additional images too. Or is it all right to alert the user that the replacement needs to be the same file type as the original if there are additional images in place? Perhaps this is just laziness?

Advice gratefully accepted. Going around in circles thinking about it.

3. I am changing my opinion a little bit about watermarking. Here's the thing. It would be nice to be able to turn it off an on. If it happens on upload then you can never get rid of it. So, I am thinking that maybe it should happen when the images are scaled? Again opinions appreciated. I have included a admin configurable option to 'always scale' even if the image is the right size already. This produces duplicate large images in some circumstances but means that the only images on the site are scaled images which in turn means that you could turn watermarking on and then clear all the scaled images and all the images on the site would then be watermarked. And vice versa.

think that is it for the moment.

niccol:

1. Additional Images.
   I believe it is correct that the additional image needs to be the same type/extension as the main image. What do you think is the best way of handling that? At the moment the additional image uploader saves the image with the correct image extension (not necessarily its own original extension) So basically the type is changed to match the main image. Is that the right way of going or would it be better to alert the user that the types need to be the same which is kind of more in keeping with the Zen standard?Not to keep bringing up Image Handler, but in IH3, if additional images uploaded are not the same format as the main image, then the UI now includes a display which shows the file type/file suffix, and it highlights the "errant" image suffix in red so that it's clear to the end user that the image is not going to display. (May add more on-screen text in the next IH update to help drive this home a little more)

niccol:

2. Further to that.
   I am working on the 'replace' the original main image function that was suggested. Here the problem is the additional images again. I am renaming them so that they still appear as additional images after the replacement. But, if the new main image is a different type should I look at changing the type of the additional images too. Or is it all right to alert the user that the replacement needs to be the same file type as the original if there are additional images in place? Perhaps this is just laziness?Functionality in Image Scaler should be consistent.. All image filetypes for each product should be the same. Therefore if the main image is a PNG, then all additional images and replacement images need to be PNGs as well.. Now you can either convert the images on the fly to the correct format or notify the end user of the issue so that they can upload the correct image type. Image Scaler needs to support this..

niccol:

3. I am changing my opinion a little bit about watermarking. Here's the thing. It would be nice to be able to turn it off an on. If it happens on upload then you can never get rid of it. So, I am thinking that maybe it should happen when the images are scaled? Again opinions appreciated. I have included a admin configurable option to 'always scale' even if the image is the right size already. This produces duplicate large images in some circumstances but means that the only images on the site are scaled images which in turn means that you could turn watermarking on and then clear all the scaled images and all the images on the site would then be watermarked. And vice versa.Watermarking is indeed a USEFUL and necessary image management feature.. IMHO (not to bring up IH3 again) it was one of the nice inclusions to Image Handler's feature set.

I have clients who are in an industry where there are a LOT of "Johnny Come Lately's" who rather than use their own images for their products will routinely STEAL images from their competitors instead.. (and you wouldn't BELIEVE the nasty messages I have exchanges with other so-called web "professionals" when asking them to take these "borrowed" images down) Clearly protecting their images as best they can is important. So watermarking is an important feature to these clients. Any image management module, needs to include this to be completely useful IMHO.

In IH3, watermarking occurs upon scaling and saving the images to the bmz_cache folders. The original images are left intact. This way if watermarking is turned off, and the bmz_cache folders are cleared, new non-watermarked images will be generated and saved to the the bmz_cache folders.

so how does IH deal with watermarking on a large image when the original is used?

regarding additonal image file types that was my question really. do we want to convert as they are uploaded or alert the user to the issue that they need to be the same file type?

niccol:

so how does IH deal with watermarking on a large image when the original is used?
Remember that IH scales ALL three sizes and loads them into the bmz_cache. (large image dimension settings are an admin configurable option added by IH) So the only images watermarked are those in the bmz_cache folder.. The original images are ALWAYS untouched..

niccol:

regarding additonal image file types that was my question really. **do we want to convert as they are uploaded or alert the user to the issue that they need to be the same file type?**Depends on are you talking an actual file conversion or simply "renaming" the file while the underlying filetype remains unchanged.. The former is a bad idea for reasons I don't even need to state here..:laugh:

But the latter is a bigger concern IMHO.. The thought of GIFs being converted on the fly to PNGs makes me cringe.. :yuck:

I think that Image Scaler should either notify the end user of the issue before any image uploading/processing happens OR allow the upload, but flag the errant image as a problematic image. With all the appropriate on-screen notices to help the end user SEE the issue.

Thanks for the advice. Certainly just advising the user that the additional images need to have the same extension as the main image is by far the easiest option for me and it seems to work for Zen.

Well gifs make me cringe anyway, to be honest. It is a weak image format in my opinion but there you go and I know that it is still used.

Nice features coming up are 'sharpen' which works really well in my opinion. :D I was kind of surprised how well that worked but so many carts have it so it better be in the mix.

Watermarking is 50% done. And that's the last thing before I post the next version.

all sounding good so far, cant wait to try it

bryan