Image Handler 4 (for v1.5.x) Support Thread

[McLovin]

Hi DivaVocals, thanks for the response. I'm not using any image swapping modules at the moment. I don't think any 'out of the box' solutions work (or at least I haven't found them yet). Right now my biggest problem is that I don't really know where to begin. Since the images are cached you end up with image names such as "071d16fadbb5599266a0e5da558f3dc0.image.300x300.jpg" placed in in different folders such as bmz_cache/0/, bmz_cache/1/, bmz_cache/2/, etc.) So I don't know of any method that would allow me to 'capture' the secondary image (in part because I don't know what it's named). I think I'll ask in a separate thread to see if anyone can give me any pointers.

[DivaVocals]

Hi DivaVocals, thanks for the response. I'm not using any image swapping modules at the moment. I don't think any 'out of the box' solutions work (or at least I haven't found them yet). Right now my biggest problem is that I don't really know where to begin. Since the images are cached you end up with image names such as "071d16fadbb5599266a0e5da558f3dc0.image.300x300.jpg" placed in in different folders such as bmz_cache/0/, bmz_cache/1/, bmz_cache/2/, etc.) So I don't know of any method that would allow me to 'capture' the secondary image (in part because I don't know what it's named). I think I'll ask in a separate thread to see if anyone can give me any pointers.

And you might want to start using the yet unreleased version of IH4 on my Github repo (search this thread for Github to find the post with the link).. no BIG changes except one.. IH4 will not name images without the MD5 hash obscuring of the image names.. Instead the image names are based on the original image name and the image dimensions..

[McLovin]

Great, thanks!

[DivaVocals]

And you might want to start using the yet unreleased version of IH4 on my Github repo (search this thread for Github to find the post with the link).. no BIG changes except one.. IH4 will now name images without the MD5 hash obscuring of the image names.. Instead the image names are based on the original image name and the image dimensions..

grrrr.. type...

[mc12345678]

Besides all that, it seems the swap process needs something known to swap with, the file naming/renaming occurs through program code, it really doesn't matter if the md5 hash or something else is used, if the same method of identifying the file is used consistently (with consideration of an image_handler involved) then this can be accomplished as well.

REALLY late in the game, but I thought that overall the md5 hash up to the renaming of the file itself made for a better directory structure/breakdown for having multiple images on a server, but I also haven't performed any serious analysis into the issue , so will continue with the good naming practices already employed. My "thought" was based on the expectation that such an analysis was performed upon implementation not just an implementation for some other reason potentially superfluous.

[DivaVocals]

Besides all that, it seems the swap process needs something known to swap with, the file naming/renaming occurs through program code, it really doesn't matter if the md5 hash or something else is used, if the same method of identifying the file is used consistently (with consideration of an image_handler involved) then this can be accomplished as well.

REALLY late in the game, but I thought that overall the md5 hash up to the renaming of the file itself made for a better directory structure/breakdown for having multiple images on a server, but I also haven't performed any serious analysis into the issue , so will continue with the good naming practices already employed. My "thought" was based on the expectation that such an analysis was performed upon implementation not just an implementation for some other reason potentially superfluous.

Ya lost me with that last part, but let me say this.. I have always thought that the MD5 hash made identification of images in the bmz_cache impossible.. It was virtually impossible to link anything with it's source image.. Also why why NOT give the cached images INTELLIGENT HUMAN SOUNDING names.. After all HUMANS need images names they can understand.. the machines don't care..

[mc12345678]

Ya lost me with that last part, but let me say this.. I have always thought that the MD5 hash made identification of images in the bmz_cache impossible.. It was virtually impossible to link anything with it's source image.. Also why why NOT give the cached images INTELLIGENT HUMAN SOUNDING names.. After all HUMANS need images names they can understand.. the machines don't care..

So it seemed to me that the md5 hash did two things. One it placed the image in a "wide" directory structure that would more than likely not result in two images having the same foldername (that's part of a hash' goal. But the second thing that I and. Many others don't agree with is that it renamed the file itself... So instead of shoes_205x205, it would be some mess of information pertinent to the "hash" and then the size... (That "mess" could have been one more directory path more with the actual filename left at the end, but that was not how it was implemented. I totally agree that the image itself should/could be provided in a sensical format (original filename plus perhaps some size indication). Further it would seem that the hash function would provide basically one unique directory path to the image and while not something sensical to us normal readers, wouldn't cause a problem with computer search tools.

Call it a balance between the two, again assuming that the hash provided a benefit beyond some computer science programmer showing that the possibility of applying a hash to a file structure. Beyond that, if the hash actually harmed the use of images (again I'm thinking of the filename remaining intact) for things of the internet, then let it be gone. But seems that there was a reason to employ it, one that may not be known any longer or perhaps is not as important as once thought.

[lhungil]

... But seems that there was a reason to employ it, one that may not be known any longer or perhaps is not as important as once thought.

The only reason a HASH would ever be needed would be if one wanted a "quick, but not perfect" COMPARE to see if one image was a copy of another image (to save on storage space). Only relevant if on a cheap host w/ limited space AND the end user was silly and uploaded multiple copies of the same image with different names or uploaded the same image to multiple different paths. Both can be avoided when necessary.

If I remember correctly (it has been a long time since I've looked at the Image Handler code), the hash was used to provide a unique name based on ONLY the path and dimensions. This is the old way image "caches" were handled in the past (computers don't care if the image name is not user friendly and the hash saves a small amount of space in the file names). As space is not a high premium anymore, newer systems simply use a unique path and the image dimensions (retains contextual information about the image in human readable format). I for one was very happy to see someone update the behavior! The more user friendly an image name is (especially for searchable images), the better IMHO.



NOTE: If one wanted, additional management and handling for images could be added. Adding new behavior and features would probably involve a new database table for images along with some refactoring of the existing Zen Cart database tables. A hash of the file contents (not name or dimensions) could be used as a "quick" compare. This is not a small undertaking and probably not worth the effort at this time. Saving a little physical space at the application level is a dying concern these days, especially with the advent of newer filesystems supporting automatic deduplication.

Currently images are all stored at the filesystem level (with unique paths - enforced by the filesystem). The product data simply references the relative path to the images and Image Handler reads this and returns the path to the corresponding Image Handler "optimized" image (creating the image if needed in bmz_cache. This behavior matches the behavior of other CMS systems such as WordPress.

[mc12345678]

The only reason a HASH would ever be needed would be if one wanted a "quick, but not perfect" COMPARE to see if one image was a copy of another image (to save on storage space). Only relevant if on a cheap host w/ limited space AND the end user was silly and uploaded multiple copies of the same image with different names or uploaded the same image to multiple different paths. Both can be avoided when necessary.

If I remember correctly (it has been a long time since I've looked at the Image Handler code), the hash was used to provide a unique name based on ONLY the path and dimensions. This is the old way image "caches" were handled in the past (computers don't care if the image name is not user friendly and the hash saves a small amount of space in the file names). As space is not a high premium anymore, newer systems simply use a unique path and the image dimensions (retains contextual information about the image in human readable format). I for one was very happy to see someone update the behavior! The more user friendly an image name is (especially for searchable images), the better IMHO.



NOTE: If one wanted, additional management and handling for images could be added. Adding new behavior and features would probably involve a new database table for images along with some refactoring of the existing Zen Cart database tables. A hash of the file contents (not name or dimensions) could be used as a "quick" compare. This is not a small undertaking and probably not worth the effort at this time. Saving a little physical space at the application level is a dying concern these days, especially with the advent of newer filesystems supporting automatic deduplication.

Currently images are all stored at the filesystem level (with unique paths - enforced by the filesystem). The product data simply references the relative path to the images and Image Handler reads this and returns the path to the corresponding Image Handler "optimized" image (creating the image if needed in bmz_cache. This behavior matches the behavior of other CMS systems such as WordPress.

Sorry haven't highlighted the pertinent part, but overall there's the explanation of why the hash function was used and why it is no longer necessary. I presumed (incorrectly) that the hash covered far less information than described. BE GONE hash filename! :) May it rest in peace having fulfilled the need that previously existed.

Thanks lhungil.

[DivaVocals]

The only reason a HASH would ever be needed would be if one wanted a "quick, but not perfect" COMPARE to see if one image was a copy of another image (to save on storage space). Only relevant if on a cheap host w/ limited space AND the end user was silly and uploaded multiple copies of the same image with different names or uploaded the same image to multiple different paths. Both can be avoided when necessary.

If I remember correctly (it has been a long time since I've looked at the Image Handler code), the hash was used to provide a unique name based on ONLY the path and dimensions. This is the old way image "caches" were handled in the past (computers don't care if the image name is not user friendly and the hash saves a small amount of space in the file names). As space is not a high premium anymore, newer systems simply use a unique path and the image dimensions (retains contextual information about the image in human readable format). I for one was very happy to see someone update the behavior! The more user friendly an image name is (especially for searchable images), the better IMHO.



NOTE: If one wanted, additional management and handling for images could be added. Adding new behavior and features would probably involve a new database table for images along with some refactoring of the existing Zen Cart database tables. A hash of the file contents (not name or dimensions) could be used as a "quick" compare. This is not a small undertaking and probably not worth the effort at this time. Saving a little physical space at the application level is a dying concern these days, especially with the advent of newer filesystems supporting automatic deduplication.

Currently images are all stored at the filesystem level (with unique paths - enforced by the filesystem). The product data simply references the relative path to the images and Image Handler reads this and returns the path to the corresponding Image Handler "optimized" image (creating the image if needed in bmz_cache. This behavior matches the behavior of other CMS systems such as WordPress.

Sorry haven't highlighted the pertinent part, but overall there's the explanation of why the hash function was used and why it is no longer necessary. I presumed (incorrectly) that the hash covered far less information than described. BE GONE hash filename! :) May it rest in peace having fulfilled the need that previously existed.

Thanks lhungil.

Let me give an even simper answer.. I didn't CARE if there was some "perceived" benefit to the MD5 hash naming used.. (and I suspect that one of the other reasons had to do with obscuring and protecting images from image thieves as well)

In any case, it's use has LONG made the images in the bmz_cache unusable for many since you couldn't match the names of the images in the cache to their original "parent" images.. So unless someone can give me a COMPELLING reason why NOT to make the change to more usable image names, I am okay that this change is an improvement for the better.. (in other words, I have NO PLANS to remove it..) and by compelling I do mean something other than providing some small means to "idiot proof" file naming for site admins.. I am not going to try and idiot proof file naming in IH4.. Folks who use poor file naming practices have historically always had issues with IH4 anyway.. The answer to that behavior is to STOP using poor file naming practices..

I will be submitting the updated IH4 this week..