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

[michaelchu]

Have been trying to upload images using IH4 and it has been a nightmare. The uploading process times out constantly, this was the same from IH3 as well. Has anyone else experienced this and is there a way to minimize this problem.

[mc12345678]

Have been trying to upload images using IH4 and it has been a nightmare. The uploading process times out constantly, this was the same from IH3 as well. Has anyone else experienced this and is there a way to minimize this problem.

No, haven't had timeout problem, what size photos are you trying to upload? (Dimensions and file size.)

[DivaVocals]

Have been trying to upload images using IH4 and it has been a nightmare. The uploading process times out constantly, this was the same from IH3 as well. Has anyone else experienced this and is there a way to minimize this problem.

need to check your error logs.. They may provide some hints as to what's happening.. post the results of your error logs along with the other information we normally as for.. (see below)

Most often this is a symptom of a server configuration limit which will terminate processing before the GD binaries can finish the image processing. Now this could be a simple server configuration change to increase memory limits so that GD can finish processing your images, but the MOST likely cause is that your original images are too large to begin with and your host's servers limits will ALWAYS stop the GD processing..

In order to determine what's going on, (and not waste time on endless guessing) you do need to provide some information.. Start with the following. Go to Tools > Server/Version Info and provide the following information:

• Zen Cart Version
• Server OS
• PHP Version
• PHP File Uploads (also tells us the max size setting)
• Database
• PHP Safe Mode

Also you don't say.. what version of IH4 are you running..

Finally what is the file size and dimensions of the image you are attempting to upload?? If POSSIBLE attach the image or provide a link where we can see the original pic in the exact size you are attempting to upload..

[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?