Resolved - Image cache purpose?

[kalyncomputers]

Can somebody explain to me why Cubecart uses an image cache?

 

It seems silly to me that the images are uploaded to the images directory and then, as far as I can see, copied to the images cache directory when they are added to a product. It seems to me to be a great waste of disk space. Is there any way that this can be circumvented?

 

And while we are on the subject of images....I have been using OSC for the last 10 years and have recently started using Cubecard 5.2.2 for a client's store. I am in the process of populating the store and as a lot of products are similar, I am cloning them and then changing the bits that need to be changed. It would be very useful if the image path was shown when you are looking at a displayed image in the image tab section of a product. OSC displays the image path as part of the product description. Perhaps the guys at Devillion could take note for a future release?

 

Tim

[bsmither]

"Why does Cubecart use an image cache?"

 

Let's start by noting that CubeCart allows for the opportunity (even if hardly ever offered) for customers to choose the skin they wish to use. This includes a mobile skin for those devices.

 

Therefore, as such, variants of the one main uploaded image with appropriate image dimensions must be made available to match the layout requirements for each skin used. Within each skin is the possibility of a cameo presentation (Featured, Sale, Latest Products boxes), thumbnail appearance (subcategory, inventory and gallery lists), and elsewhere (invoices, main category, and main gallery enlarged). Third-party skins may have additional sized layout requirements.

 

The argument could be made that, just let the browser re-size the one image according to the style properties.

 

My only best-guess answer is that CubeCart offers "hooks" into the whole process of creating these variants, such that the PHP extension, "GD", can be sufficiently programmed to add effects to a source image. Some effects may be: a watermark, a ribbon on the corner saying something (in a target language perhaps). There may be the case where a browser (probably none that are modern) cannot correctly re-size a small GIF to a larger size.

 

Or instead of a simple re-size, a hook tells GD to crop to the size needed.

 

Granted, as of CC522, none of this has been seen implemented, but the possibility is there.

 

I would disagree that this scheme results in a great waste of disk-space. Each image should be no more than 20k (in my experiments).

 

CubeCart5 is 99% human-readable, so, yes, it is possible to circumvent the image cache and associated code, and rely on the browser doing the re-sizing -- assuming the skin has the necessary image dimensions declared.

 

I just now discovered that an image I use in my experiments is:

Orig: 6k 225x225

600: 10k 225x255

580: 20k 225x225

270: 10k 225x225

138: 3.5k 138x138

  70: 1.6k 70x70

 

I would have thought that the images would be the actual required size. I will have to look into that.

[kalyncomputers]

Hi,

 

Thanks for your detailed explanation, the way that CC works with images now makes a lot more sense and I am grateful to you for helping me understand. I agree that it doesn't result in  'greater disk space' usage but when you have a large store, it may make a difference. For us store designers, it is fairly simple to resize images but for most of my clients it is a task way beyond their capabilities! 

 

Thanks again

 

Tim