Like I said I turned the hover thing off, so it wouldn't do it anymore. My site is http://www.joannes-digital-designs.com/shop/
Like I said I turned the hover thing off, so it wouldn't do it anymore. My site is http://www.joannes-digital-designs.com/shop/
Has anyone experienced issues when using png images?
Original png is 60.64Kb
IH4 creates a medium at 687.09Kb, and a small at 76.48Kb
If that's a bug, it's a pretty serious one.
IH4.3.2 running on ZC 1.5.5e
Also tested IH5 beta and experienced the same issue.
It's using png because that's what the site owner uploaded. Several hundred of them! And yes, he's using transparency.
I'm not here to debate the use of one image format over another though as that's a moot point when the images already exist.
Simple fact is that IH doesn't work correctly with png images, and that has been proven by soxophoneplayer who tested it himself.
Clearly this is a bug. If it's not a fixable one, then there is little point in png being processed by IH as the file sizes are simply ridiculous, and support for png might as well be removed.
Have you played around in
Configuration->Images and altered the compression settings
IH small images compression quality
IH medium images compression quality
IH large images compression quality
to see if this helps out.
Googling png images comes up with lots of issues regarding file sizes and image quality
So it may not totally be IH's fault but may be a problem with png and the underlying "server" software that manipulates the images on the server.
there really is no reason why either GD or ImageMagick cannot scale a .png image correctly. I can demonstrate that but I do not think I need to. Both technologies are well proven. If IH is creating smaller images that have greater file sizes there is either something funky going on in the code or there is something funky going on with the images.
The thing that those who believe it is a bug should do next is to create an absolutely simple .png image. So, go to photoshop/gimp/whatever and create a 1000X1000 image with a solid fill colour and nothing else. Save the image as a .png. Then see if you are experiencing the same issues when IH tries to scale that image. If you are then you have ruled out the 'something funky with your images' option.
If it is then the next step will be to work out if the server is running ImageMagick and/or GD (I am not sure what IH uses any more as I am a well-documented non-user of IH). I'd guess IH uses ImageMagick by preference but drops to GD if needed. Either way, find out what the server is using and then find out (by google or by asking your hosting company) how to scale an image directly on the server using ImageMagick (or GD). Do that with the test image you have created. If that directly scaled image is larger file size then you have shown that the problem is server related. If it is not larger then you have shown that it is an IH issue.
As I say, I am not a fan of IH anyway (just because it does something very simple in a very complex way) so am not all that interested in spending a whole lot of time on this but the steps above will allow you to identify where the problem is occuring.
Nick
iszent.com
I, too, just tried a .png image (with additional images):
Image 1: 328 x 370 (228KB)
Image 2: 1213 x 584 (1.28MB)
When run through IH5 (note that its processing hasn't changed from IH4), this produced:
Image 1: 70 x 80 (22KB), 106 x 120 (49.9KB)
Image 2: 100 x 48 (18.8KB), 150 x 72 (42.3KB), 750 x 361 (1.02MB)
That said, there's more to the .png file "expansion" than just the file type. Perhaps the original file's size?
OK, the file size matters! Tried again with an additional image 183 x 275 (11.2KB), which produced images 53 x 80 (16.7KB) and 79 x 120 (37.2KB).
The issue's source lies in the save_imageGD function present in /includes/classes/bmz_image_handler_class.php:
I'm guessing that most stores use the default quality configuration values of 85, which is what I'm using for my investigation. I'll also note that the documentation for the imagepng function's 3rd input (quality) indicates that the value should be an integer in the range 0 to 9.Code:public function save_imageGD($file_ext, $image, $dest_name, $quality = 75) { global $ihConf; switch (strtolower($file_ext)) { case '.gif': if(!function_exists("imagegif")) return false; $ok = imagegif($image, $dest_name); break; case '.png': if(!function_exists("imagepng")) return false; $quality = (int)$quality/100; $ok = imagepng($image, $dest_name, $quality); break; case '.jpg': case '.jpeg': if(!function_exists("imagejpeg")) return false; $ok = imagejpeg($image, $dest_name, $quality); break; default: $ok = false; } imagedestroy($image); return $ok; }
I made a slight change to the function, sanitizing that quality input, with the resultant files being 7.95KB and 15.8KB respectively.
That looks like a start! I'll be posting that update to the IH5 GitHub repository.Code:public function save_imageGD($file_ext, $image, $dest_name, $quality = 75) { // ----- // Initially, santitize the quality input for use by imagejpeg; values should // be in the range 0-100. // $quality = (int)$quality; if ($quality < 0 || $quality > 100) { $quality = 75; } switch (strtolower($file_ext)) { case '.gif': if(!function_exists("imagegif")) return false; $ok = imagegif($image, $dest_name); break; case '.png': if(!function_exists("imagepng")) return false; // ----- // The quality input for imagepng requires an integer value in the // range 0-9. If the value's out-of-range, use a proportional setting // based on the input. // if ($quality > 9) { $quality = (int)(9 * $quality / 100); } $ok = imagepng($image, $dest_name, $quality); break; case '.jpg': case '.jpeg': if(!function_exists("imagejpeg")) return false; $ok = imagejpeg($image, $dest_name, $quality); break; default: $ok = false; break; } imagedestroy($image); return $ok; }
Have Zencart 1.5.4 When I click on a product that uses Image Handlet, I get a blank page with just one photo. just one page with the issues Just click on any item. one of my logs
Code:[24-Dec-2017 14:10:03 UTC] PHP Warning: Illegal string offset 'cPath' in /home/cubmanky1/public_html/store/includes/classes/navigation_history.php on line 40 [24-Dec-2017 14:10:03 UTC] PHP Warning: Illegal string offset 'products_id' in /home/cubmanky1/public_html/store/includes/classes/navigation_history.php on line 40 [24-Dec-2017 14:10:03 UTC] PHP Warning: A non-numeric value encountered in /home/cubmanky1/public_html/store/includes/classes/categories_ul_generator.php on line 58 [24-Dec-2017 14:10:03 UTC] PHP Warning: A non-numeric value encountered in /home/cubmanky1/public_html/store/includes/classes/categories_ul_generator.php on line 73 [24-Dec-2017 14:10:03 UTC] PHP Warning: A non-numeric value encountered in /home/cubmanky1/public_html/store/includes/classes/categories_ul_generator.php on line 73 [24-Dec-2017 14:10:03 UTC] PHP Warning: A non-numeric value encountered in /home/cubmanky1/public_html/store/includes/classes/categories_ul_generator.php on line 73 [24-Dec-2017 14:10:03 UTC] PHP Fatal error: Uncaught Error: Cannot use string offset as an array in /home/cubmanky1/public_html/store/includes/modules/responsive_sheffield_blue/additional_images.php:114 Stack trace: #0 /home/cubmanky1/public_html/store/includes/templates/template_default/templates/tpl_modules_additional_images.php(13): require() #1 /home/cubmanky1/public_html/store/includes/templates/responsive_sheffield_blue/templates/tpl_product_info_display.php(83): require('/home/cubmanky1...') #2 /home/cubmanky1/public_html/store/includes/modules/pages/product_info/main_template_vars.php(178): require('/home/cubmanky1...') #3 /home/cubmanky1/public_html/store/includes/templates/responsive_sheffield_blue/common/tpl_main_page.php(251): require('/home/cubmanky1...') #4 /home/cubmanky1/public_html/store/index.php(97): require('/home/cubmanky1...') #5 {main} thrown in /home/cubmanky1/public_html/store/includes/modules/responsive_sheffield_blue/additional_images.php on line 114
Bookmarks