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

[michaelchu]

After some more testing, it appears that IH4 image upload doesn't play nice with Safari. Same exact set of images loaded just fine using Firefox.

[Invizix]

Is this fully functional with the current/newest Zen Cart v1.5.4 release? Thanks.

[McLovin]

Hi Guys,

I was wondering whether anyone could help me with the following problem. I'm currently running Zen Cart v.1.5.1 and Image Handler 4. I've noticed that certain images actually end up larger after compression and/or re-sizing. I have no idea why this happens as the original images are all identical (jpeg, same size, same export settings, etc.) and it only happens to some images. Has anyone encountered this problem before and if so, what could be the problem?

Thnx!

[DivaVocals]

Hi Guys,

I was wondering whether anyone could help me with the following problem. I'm currently running Zen Cart v.1.5.1 and Image Handler 4. I've noticed that certain images actually end up larger after compression and/or re-sizing. I have no idea why this happens as the original images are all identical (jpeg, same size, same export settings, etc.) and it only happens to some images. Has anyone encountered this problem before and if so, what could be the problem?

Thnx!

Nope, and honestly hard to say without seeing the files where this happens, comparing to files where this does not happen.. Could be something in the underlying file meta data, server anomalies, etc.. Too many variables to name.. Finally since it is the GD binaries actually doing the "heavy lifting" the issue could be related specifically to GD processing these images in a different way having something to do with the file's underlying structure/metadata..

**shrugs**

Can't say for sure..

[McLovin]

Nope, and honestly hard to say without seeing the files where this happens, comparing to files where this does not happen.. Could be something in the underlying file meta data, server anomalies, etc.. Too many variables to name.. Finally since it is the GD binaries actually doing the "heavy lifting" the issue could be related specifically to GD processing these images in a different way having something to do with the file's underlying structure/metadata..

**shrugs**

Can't say for sure..

Thanks for the quick feedback!

I've tried to add the two original images as an attachment with a screenshot of what happens with the image sizes after compression by Image Handler 4, but I'm afraid the forum File Handler automatically compresses the original images. So instead I've uploaded them to DropBox:

https://www.dropbox.com/sh/orel6urew...d0JVQd6Ca?dl=0

The first screenshot (normal.jpg and bones-fashion-handtas-a1b2c3-1.jpg) is what normally happens: the image is compressed and/or re-sized without any problems. The second image (larger_after_compression.jpg and bones-fashion-handtas-a1b2c3-5.jpg) however causes problems: it increasing in size after compression and/or re-sizing.

I have no idea what might be wrong, as the export procedure for these images is identical. All images have the same structure, metadata, batch, etc. As for the server configuration, I suspect it would have to be quite an exceptionally rare anomaly, as Image Handler works correctly on most images...

[DivaVocals]

Thanks for the quick feedback!

I've tried to add the two original images as an attachment with a screenshot of what happens with the image sizes after compression by Image Handler 4, but I'm afraid the forum File Handler automatically compresses the original images. So instead I've uploaded them to DropBox:

https://www.dropbox.com/sh/orel6urew...d0JVQd6Ca?dl=0

The first screenshot (normal.jpg and bones-fashion-handtas-a1b2c3-1.jpg) is what normally happens: the image is compressed and/or re-sized without any problems. The second image (larger_after_compression.jpg and bones-fashion-handtas-a1b2c3-5.jpg) however causes problems: it increasing in size after compression and/or re-sizing.

I have no idea what might be wrong, as the export procedure for these images is identical. All images have the same structure, metadata, batch, etc. As for the server configuration, I suspect it would have to be quite an exceptionally rare anomaly, as Image Handler works correctly on most images...

Like I said, I couldn't really say, and I personally do not have free time available to really dig in and analyze the files you shared.. I can only share what I know about how this thing works under the hood. I am certain however that the REAL cause has to do with the way GD is interpreting and then processing your files..

Other things that may impact this how GD reads your files for processing.

• Files converted from one format to another. (GIF to JPG or PNG to JPG) If the image software does not correctly convert the file, GD will attempt to detect and correct when processing the file.
• Files "converted" by simply changing the file extension versus actually converting the file using an image editing software will DEFINITELY be processed with unexpected results by GD

• Corrupted files.
  Recent example of this: Using lat9's backtrace tool and having IH4 code set to allow GD error messages to be logged, allowed me to discover that a client had MULTIPLE jpg files which were corrupted/invalid. On the front-end these files were all viewable, but on the back-end GD rejected them for processing so there were no optimized images for these particular files. GD sent error messages every time this product was viewed because IH4 attempts to process images on the fly (via GD of course). Opening, re-saving, and then re-uploading these files allowed GD to re-process them with no errors. Do I know EXACTLY what was wrong with these files?? Nope.. Could have been ANYTHING (including the issues I names above).

[kabko]

It says IH4 is compatible with v1.5.0, v1.5.1

Is this release v4.3.2 compatible with ZC 1.5.4 please?

Did anyone try to install this with ZC 1.5.4?