Jump to content

Animated GIF resize issue


j00st
 Share

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?

 

 

Link to comment
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
Link to comment
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?

Link to comment
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.

Link to comment
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...
 

Link to comment
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...

Link to comment
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.

Link to comment
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
Link to comment
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...

Link to comment
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
Link to comment
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)

Link to comment
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
Link to comment
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!!

 

Link to comment
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
Link to comment
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?
 

Link to comment
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?

Link to comment
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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...