Jump to content
j00st

Animated GIF resize issue

Recommended Posts

Hi everyone! 
 

So I've been going over all the Animated GIF topics before posting this, but unfortunately I'm none the wiser at the moment.
I'm super happy Horst's module has been included into the Core install, but as you might guess...I'm still having issues with my Animated GIFs 😞

CMS & File checklist:
Double-checked if the module is installed = YES
Correct upload of GIF = YES
Testing GIF has 72dpi & is 1000x1000px & 563kb = Shouldn't cause any problem, right?
Uploaded GIF still shows animation in backend = YES
ProcessWire is up to date = 3.0.108

Front-end tests:
Tried the following code, to see if it had to do with the way I'm resizing, but 
both with no results.

<?php echo $img->width(720)->url?>
<?php echo $img->size(720, 0)->url?>

Here's the big catch though: 
If I just echo the $img->url it will show the GIF...so it has to do with the resizing...but this is where I got stranded...

UPDATE:
Just in case, I also added the PHP & MySQL versions I'm running. Server's online not local.
PHP 5.6.32 (in the overview) ----> But it's in fact, when going to the PHP admin, it's running PHP 7.0. Any chance this is what's causing the issue?
MySQL 5.6.23-78.1

Any tips?

 

 

Share this post


Link to post
Share on other sites

I can confirm this behaviour, also with the latest PW version. All API-generated (resized) versions are not animated anymore. PHP Version 5.6.36. Reminds me... I should update this instance to v. 7.x as well 😐

  • Thanks 1

Share this post


Link to post
Share on other sites
Just now, dragan said:

Seems like ImageMagick has problems maintaining all the frames, it just takes the first one and disregards the rest.

I think I remember reading something about that; it was also the case why the plug-in was initially made, as it has to do with a re-compiling of all the 'layers' of the GIF, instead of resizing just one image. So perhaps, because it's now using ImageMagick, a similar issue is coming up?

Share this post


Link to post
Share on other sites

Hhm, did you have installed / enabled the animated gif module?

Which version is it?

Which number in the internal modules hirarchy does it have? And which other modules and hirarchy numbers are installed?

 

The animated gif module doesn't rely on IMagick.

Share this post


Link to post
Share on other sites

Thanks for the response horst!!

Q: Hhm, did you have installed / enabled the animated gif module?

A: Nope, didn't have it installed, only the Animated GIF Image Sizer (v0.0.1) that's included in the core. That looks to be fully enabled, as it part of the core I'm not sure I could even change that, right? I tried installing the module you made before, but as I've updated to PW 3.0.108 it discontinues installation as it's already in the core.

Q: Which version is it?

A: Animated GIF Image Sizer (v0.0.1)
ProcessWire 3.0.108 (latest?) (Initial install was 3.0.9, updated to 3.0.98, then this one)

Q: Which number in the internal modules hirarchy does it have? And which other modules and hirarchy numbers are installed?

A: You mean ImageSizerEngine Module priority with this right? I double-checked, IMagick was on 1, and AnimatedGif was on 9. Changed it around so the AnimatedGIF is on 1, and IMagick is on 2. I'm not aware of any other ImageSizerEngine modules being installed (by myself that is). And the only additional Module that I've installed that has something to do with images is ImageExtra (but as that's for additional textfields I thought that couldn't be the case?) 
If you do mean something else by the internal module hierarchy, please let me know 🙂

Also, another thought that crossed my mind – as we're talking about images – I'm using picturefill, but not in the same place as the animated GIFs. So I thought this also couldn't be the problem. But I thought I'd put it down here, just in case...
 

Share this post


Link to post
Share on other sites
4 minutes ago, j00st said:

Also, another thought that crossed my mind – as we're talking about images – I'm using picturefill, but not in the same place as the animated GIFs. So I thought this also couldn't be the problem. But I thought I'd put it down here, just in case...

Double-checked, I need to correct that. I AM using the picturefill. And what's more -> the lowres (preview) IS working as GIF, but the final image isn't...so perhaps it does have something to do with picturefill...

Share this post


Link to post
Share on other sites

@horst

So I removed the picturefill function, and lazysizes (which was also active), just to make sure.

At the moment I (still) have:
- Animated GIF Image Sizer (v0.0.1) activated
- ProcessWire 3.0.108

This is running on a local system operating MAMP v5.0 (334), with PHP 7.1.19 & MySQL 5.7.21
Online it's running on something similar, but for both cases the following has negative result:

<?php
    $test = $img->url;
    $test2 = $img->width(1440)->url;
    $test3 = $img->size(1440, 0)->url;
?>

<img class="double" src="<?php echo $test2; ?>"/>

That's the most basic I could test right?
$test works fine, URL of original image is still animated.
$test2 & $test3 – no more animation in the image.

Share this post


Link to post
Share on other sites

Everything looks good.

Please can you try the following code snippets in a template file:

$imgPath = $config->paths->files . '1/animated.gif'; // add the full path to an original animated gif here!!

$ii = new ImageInspector();
$info = $ii->inspect($imgPath, true);
var_dump($info);

$is = new ImageSizer($imgPath);
var_dump($is->getEngines());

$shortInfo = $is->getImageInfo();
var_dump($shortInfo);

and check the output?

The first var_dump() should have a true under "info"->"animated", and the second one only should have one array item named "ImageSizerEngineAnimatedGif".

If this is the case, we need to check further.

 

Edited by horst
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Tested, and both with correct/expected output:

The first var_dump() should have a true under "info"->"animated"
["info"]=>["animated"]=> bool(true)

And second one:
array(1) { [0]=> string(27) "ImageSizerEngineAnimatedGif" }

So those two check out...

Share this post


Link to post
Share on other sites

?? - can you PM me that image?

Is it with all animated images or only with special ones? DO you have set the option to force a recreation of the variations? ("forceNew" => true)
otherwise you always get the previously cached version.

<?php
    $test = $img->url;
    $test2 = $img->width(1440, array("forceNew" => true))->url;

 

Edited by horst
added code example with "forceNew" option

Share this post


Link to post
Share on other sites

Image is in your inbox 🙂 THanks for checking it out.

I tried the "forceNew" but now get the following error (on my local environment):
Error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 8192 bytes)

But the image isn't that big, so I'm wondering what's happening here...curious to see what you make of it!

It's with all animated images (so far at least)

Share this post


Link to post
Share on other sites

Hi @j00st,

I have checked your images. They are alright, nothing suspicious. When I set the memory_limit to under 96M, it wasn't possible to resize a single image. WIth set to 96M, it was most of the time, but sometimes not, when resizing multiple images in one script run.

You have set it to 128M on your host. If you are able, increase it to 256M.

Animated images gets extracted slide for slide into memory. Each slide is processed in a single conversion process and consumes three times the memory of the single slide. Also the process includes a flushing and releasing of no further needed objects and memory, this is known to be buggy (or unclean) in PHP.

So, the issue on your host definetly is assigned to low allowed memory usage for (php) image processing.

If you set debug to true, every resize action is logged into "image-sizer" log under admin->setup->logs. And you definetly need to use "forceNew" in your resize calls when debugging and testing!

  • Thanks 1

Share this post


Link to post
Share on other sites

Hi @horst

Thanks for all the work! Good to know the images are ok 🙂

I went ahead and checked the memory_limit, on the server it was already set to 256M, and my local server was doing 128, which I upped to 256 as well.
But...I still get the error message about not being able to allocate the data/bytes...So could it be that the GIF is in some way still too big? (Or long in duration?)
The server I'm using is on Bluehost, which advises not to increase past 128 – but it was already set higher...so I'm also kind of surprised there.
So unfortunately. still errors – which is weird, because I've been using it elsewhere/on older PW versions without issues.

Good to know about the forceNew and logs!! Hadn't realised and/or heard of this before, so that's definitely something I'm going to put to use in the future!!

 

Share this post


Link to post
Share on other sites

You can check the real available memory on the frontend:

echo "<p>" . ini_get("memory_limit") . "</p>";

Maybe, the settings from the adminpanel are not passing through?

 

No, the images are not to big. with more than 128M, for me they work everytime.

And if the process would took to long, you would get a timeout error, but not one for to low memory.

Edited by horst

Share this post


Link to post
Share on other sites

Another superb tip 😀 

So both on local & server it shows 256M available...

Meanwhile I thought I'd also see if somewhere on the world wide web someone else is running into something similar,
landing me on Stackoverflow, to be precise this thread.

Quoting from that thread:

Quote

Finally with the help of the server administrator, he found that the problem lies in MySQL database column definition. one of the columns in the a table was assigned to 'Longtext' which leads to allocate 4,294,967,295 bites of memory. It seems working OK if you don't use MySqli prepare statement, but once you use prepare statement, it tries to allocate that amount of memory. I changed the column type to Mediumtext which needs 16,777,215 bites of memory space. The problem is gone.
 

Could this be something that's happening in this case as well? Making it a MySQL rather then a PHP problem?
 

Share this post


Link to post
Share on other sites

I don't think it can have to do with MySQL in this case. Never have heard of this. But often heard about it in regard with image resizing.

Would it be possible to temporary allow me to inspect this on the server, maybe if it is a staging account?

Share this post


Link to post
Share on other sites

For those following along, or running into similar problems, these are my findings so far...

1. I've been testing the images with ForceNew, and found (on my local server) that with width(1000) it's fine, but any bigger it throws an error.

2. I've updated the code so that the width = 1000 when resizing. This seems to work. Setting it back to a higher width doesn't throw an error anymore (on the server), but still only loads the first image of the GIF, instead of an animated GIF

What I reckon I'll do for now, is actually setup a PHP check for GIFs, as some images are displayed at full-screen-width (with a max of 1280px) so those I'd preferably not down-size to 1000. For the GIFs I guess, as they are already 'lower res' it's a partial solution. Still looking into it though.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Clément Lambelet
      Hi all,
       
      I'm really new to ProcessWire, maybe I missed the solution in the documentation.
      I'm working on a site which involves a lot of image upload fields, and I'm always getting many timeout errors. I'm pretty sure it's because I generate too many variations on a single page load (around 20 images with 7 different sizes, for them to be responsive).
      I can't use ImageSizerEngineIMagick to help (my host doesn't support it).
       
      I was wondering if there was a way to hook to the process of client-side image resizing (https://processwire.com/blog/posts/processwire-3.0.63-adds-client-side-image-resizing/) to generate the different variations (as it seems really faster). If not, is there a way to generate the different variations on upload and not on page load ?
       
      Any ideas and suggestions are welcome!
    • By Robin S
      Inspired by the "max megapixels" option for the client-side image resizer, I made a simple module that adds target megapixel resizing for Pageimages.
      Image Megapixels
      Adds a method for Pageimages that resizes to a target megapixel value.
      Example use
      You are creating a lightbox gallery of images with different aspect ratios. For the enlargements, rather than setting a fixed maximum width or height you want all the enlargements have the same size in terms of area, allowing a panoramic image to be wider than a square image, for instance.
      The effect of resizing three different aspect ratios by the same megapixel target value can be seen in the screenshot below:

      Installation
      Install the Image Megapixels module.
      API
      // basic usage $pageimage = $pageimage->megapixels(float $megapixels); // usage with all arguments $pageimage = $pageimage->megapixels(float $megapixels, array $options = []); Example:
      foreach($page->images as $image) { echo "<img src='$image->megapixels(0.8)->url' alt='$image->description'>" } If needed you can supply an array of options for Pageimage::size() as a second argument.
       
      https://github.com/Toutouwai/ImageMegapixels
    • By jploch
      Hi!
      I have a problem with uploading animated GIFs again.
      The upload starts, but never finishes and just loads forever.
      Iam running PW 3.0.62 and have the Image Animated GIF Module installed.

      I also increased the memory limit in the htaccess file in PW root directory like this:
      <IfModule mod_php5.c>
      php_value memory_limit 256
      php_value upload_max_filesize 64M
      php_value post_max_size 64M
      php_value max_execution_time 300
      php_value max_input_time 1000
      </IfModule> 
      I had this problem before, but was able to fix it with the Animated GIF Module and the modification of the htaccess file.
      So maybe this is related to the provider (strato).
      Here is the error I get, when uploading the GIF (1.1 MB filesize)
      Warning: preg_match_all() expects at least 3 parameters, 2 given in /mnt/web216/a2/50/51925650/htdocs/processwire/wire/core/PWGIF.php on line 252 Warning: preg_match_all() expects at least 3 parameters, 2 given in /mnt/web216/a2/50/51925650/htdocs/processwire/site/assets/cache/FileCompiler/site/modules/ImageAnimatedGif/ImageAnimatedGif.module on line 285 Warning: preg_match_all() expects at least 3 parameters, 2 given in /mnt/web216/a2/50/51925650/htdocs/processwire/wire/core/PWGIF.php on line 252 Warning: preg_match_all() expects at least 3 parameters, 2 given in /mnt/web216/a2/50/51925650/htdocs/processwire/wire/core/PWGIF.php on line 252 Warning: preg_match_all() expects at least 3 parameters, 2 given in /mnt/web216/a2/50/51925650/htdocs/processwire/site/assets/cache/FileCompiler/site/modules/ImageAnimatedGif/ImageAnimatedGif.module on line 285 Warning: preg_match_all() expects at least 3 parameters, 2 given in /mnt/web216/a2/50/51925650/htdocs/processwire/wire/core/PWGIF.php on line 252 [{"error":false,"message":"Added file: test.gif","file":"\/processwire\/site\/assets\/files\/1098\/test.gif","size":101734,"markup":"<li id='file_daf280af792fd5b906511363ae2bc39d' class='ImageOuter gridImage ui-widget'><div class='gridImage__tooltip'><table><tr><th>Dimensions<\/th><td>500x333<\/td><\/tr><tr><th>Filesize<\/th><td>99&nbsp;kB<\/td><\/tr><tr><th>Variations<\/th><td>0<\/td><\/tr><\/table><\/div>\n\t\t\t<div class='gridImage__overflow'>\n\t\t\t\t<img src=\"\/processwire\/site\/assets\/files\/1098\/test.0x260.gif?nc=1509109293\" alt=\"\" data-w=\"500\" data-h=\"333\" data-original=\"\/processwire\/site\/assets\/files\/1098\/test.gif?nc=1509109293\" \/>\n\t\t\t<\/div>\n\t\t\t\n\t\t\t\t<div class='gridImage__hover'>\n\t\t\t\t\t<div class='gridImage__inner'>\n\t\t\t\t\t\t<label for='' class='gridImage__trash'>\n\t\t\t\t\t\t\t<input class='gridImage__deletebox' type='checkbox' name='delete_thumbnail_daf280af792fd5b906511363ae2bc39d' value='1' title='Delete' \/>\n\t\t\t\t\t\t\t<span class='fa fa-trash-o'><\/span>\n\t\t\t\t\t\t<\/label>\n\t\t\t\t\t\t<a class='gridImage__edit'>\n\t\t\t\t\t\t\t<span>Edit<\/span>\n\t\t\t\t\t\t<\/a>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\t\t\t\t<div class='ImageData'>\n\t\t\t\t\t<h2 class='InputfieldImageEdit__name'><span contenteditable='true'>test<\/span>.gif<\/h2>\n\t\t\t\t\t<span class='InputfieldImageEdit__info'>99&nbsp;kB, 500&times;333 <\/span>\n\t\t\t\t\t<div class='InputfieldImageEdit__errors'><\/div>\n\t\t\t\t\t<div class='InputfieldImageEdit__buttons'><small><button type='button' data-href='\/processwire\/admin\/page\/image\/edit\/?id=1098&file=1098,test.gif&rte=0&field=thumbnail' class='InputfieldImageButtonCrop ui-button ui-corner-all ui-state-default pw-modal-large pw-modal' data-buttons='#non_rte_dialog_buttons button' data-autoclose='1' data-close='#non_rte_cancel'><span class='ui-button-text'><span class='fa fa-crop'><\/span> Crop<\/span><\/button><button type='button' data-href='\/processwire\/admin\/page\/image\/variations\/?id=1098&file=test.gif&modal=1&varcnt=varcnt_thumbnail_daf280af792fd5b906511363ae2bc39d' class='ui-button ui-corner-all ui-state-default pw-modal-large pw-modal' data-buttons='button'><span class='ui-button-text'><span class='fa fa-files-o'><\/span> Variations <span class='ui-priority-secondary'>(0)<\/span><\/span><\/button><\/small><\/div>\n\t\t\t\t\t<div class='InputfieldImageEdit__core'><div class='InputfieldFileDescription'><label for='description_thumbnail_daf280af792fd5b906511363ae2bc39d' class='detail'>Description<\/label><input type='text' name='description_thumbnail_daf280af792fd5b906511363ae2bc39d' id='description_thumbnail_daf280af792fd5b906511363ae2bc39d' value='' \/><\/div><\/div>\n\t\t\t\t\t<div class='InputfieldImageEdit__additional'><\/div>\n\t\t\t\t\t<input class='InputfieldFileSort' type='text' name='sort_thumbnail_daf280af792fd5b906511363ae2bc39d' value='1' \/>\n\t\t\t\t\t<input class='InputfieldFileReplace' type='hidden' name='replace_thumbnail_daf280af792fd5b906511363ae2bc39d' \/>\n\t\t\t\t\t<input class='InputfieldFileRename' type='hidden' name='rename_thumbnail_daf280af792fd5b906511363ae2bc39d' \/>\n\t\t\t\t<\/div>\n\t\t\t<\/li>","replace":true,"overwrite":0}]  
    • By benbyf
      Running into Error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 12288 bytes) (line 190 of /srv/users/serverpilot/apps/hortons/public/site/modules/ImageAnimatedGif/ImageAnimatedGif.module)
      I'm running PW 3.0.42. Not come across this before on a image field with a gif uploaded, anyone have any insight?
      Thanks
×
×
  • Create New...