max image dimensions - "not a recognized image" [bug?]

[bernhard]

hi everyone,

i just noticed the "max image dimensions" function of processwire image field (i thought it would reject images bigger than that size and not resize it to that maximum ) and tried it on several installations but unfortunately i get the following error on most of the new 2.5 ones:

first i thought it was a server issue, but i tried it with a fresh installation on lightning.pw and there's the same error!

i set 1920x1080 for the max dimensions.

if i don't set a maximum i get this error on large images:

did i miss anything? can anyone replicate that issue?

[horst]

This is by design. and everyone can replicate it by simply setting the amount of memory way to small for such large images on his server.

So, the error message in the first example isn't that lucky because you see the error from the derivative image (admin thumbnail 0x100) what could not be created from the way to large original image that should be scaled down to a max-size. If you have a look into the original image (open it in a simple plain text editor!) you will see that it contains something like:

This is intentionally invalid image data.
basename.1920x1080.jpg - not enough memory to load/resize

whereas the 0x100 thumb contains:

This is intentionally invalid image data.
basename.0x100.jpg - not a recognized image

@Ryan: Maybe we need to display the error from original image too so that it is more clear what was going on?

So, but in your second example you can already read it by yourself: not enough memory to load/resize

Imagerendering with the GD-lib needs minimum ram memory 2 - 2.5 times of the uncompressed image! If you load to large images into memory GD/PHP crashes with a not catchable fatal error. PW since version 2.5 does look ahead to available memory at runtime before loading images into memory. This way it saves you from crashes!

I like how it works. Great job @Ryan!

Simple calculation example with your image:

width x height x colorchannels  = memory bytes

4.608 x 3.456  x      3                  =    47.775.744         

- just to load one of those images into memory (togehther with rest of PW) you need 60MB ram!

- and if you want to manipulate / resize it you need 47.775.774 x 2.3 = 109.884.211.

Do you have a minimum of 128MB memory available for PHP?

No, you need to bump it up.

I recommend setting it higher in available server configuration panels, php.ini file or in the .htaccess:

<IfModule mod_php5.c>
    php_value memory_limit 256M
</IfModule>

But you should not transmit images 4 times larger than the largest needed display size. (Denk an unsere Umwelt und an unsere Kinder die diese auch noch brauchen!) g-translate: (Remember our environment and our children also need this yet) 

Edited September 29, 2014 by horst

[bernhard]

hi horst,

thank you for your detailed answer.

This is by design. and everyone can replicate it by simply setting the amount of memory way to small for such large images on his server.

hm, i forgot to mention that on an older installation (2.4.x) on the same server with exactly the same php settings it works wonderfully!

first i thought it could have something to do with my multisite setup at the non functional 2.5 site, but a single-site setup showed the same result (also on lightning.pw)

so the actual question is: why does it work on my some week old installation? (of course i used the same image)

But you should not transmit images 4 times larger than the largest needed display size. (Denk an unsere Umwelt und an unsere Kinder die diese auch noch brauchen!) g-translate: (Remember our environment and our children also need this yet) 

yes, that's clear to me - but tell that my clients...

ps: memory_limit is set to 128M in all of the mentioned environments (one vserver)

[horst]

hm, i forgot to mention that on an older installation (2.4.x) on the same server with exactly the same php settings it works wonderfully!

so the actual question is: why does it work on my some week old installation? (of course i used the same image)

ps: memory_limit is set to 128M in all of the mentioned environments (one vserver)

Hi Bernhard,

ok, that is important information.

Best bet is that this case is very near to the limit. One cannot exactly know how many memory an image manipulation will need. But if we calculate to small, the whole thing is obsolete, because it can crash the script as it was before. The cullprit is that there is only one setting for factor that should suite for all possible cases (downsizing, upsizing, croping, etc)

The line in code where it is set is here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ImageSizer.php#L1614, also I see it's default is 2.5, not 2.3. Maybe you can set it to 2.3 (or 2.2) and try again?

Using factor 2.3 insteed of 2.5 results in 10MB more memory in this case. Only 109 estimated and not 119 of 128.

[bernhard]

hi horst,

thank you for the quick reply! i changed it to 2.0 and it worked!

so to clarify... if i had a vserver with multiple sites it could be that the same image works once and doesn't work another time, depending on server load (curMem)?

and regarding the error message: i'm quite new to github, where would i post request to return a more meaningful error message? especially for clients...

thank you for your help

[horst]

thank you for the quick reply! i changed it to 2.0 and it worked!

hmm, 2.0 can be to small. With the tests 2.2 was the smallest setting what never has failed. 2.1 has failed sometimes.

so to clarify... if i had a vserver with multiple sites it could be that the same image works once and doesn't work another time, depending on server load (curMem)?

good question.    I don't know how vservers are configured and or how the memory management work in those web machines. As far as I have understood it until now is that the 128M, if it is set to this, is guaranted for every starting script. Otherwise it doesn't make sense to me. If on a server with 16G mem are 50 sites / accounts, each can have a guaranted minimum of 320MB. If this isn't enough, maybe it can use more "if available". If there is heavy server load and there is more needed, maybe some technic like swapfiles came into play? In fact I don't know. But guaranted doesn't mean it lets you script die / crash. Maybe slow down, delayed, but not crash in the first instance. Or?

and regarding the error message: i'm quite new to github, where would i post request to return a more meaningful error message? especially for clients...

You need to go to the dev-branch and select "issues" from the tabs on the right (that one with the exclamation mark). Their you can post a new one. You may also include a link to a forums post / thread if this can be helpful for Ryan.

[benbyf]

Having a similar issue but only getting this error:

This is intentionally invalid image data. sizzle_02_o.450x0.jpg - not a recognized image

Is this again to do with RAM? If so is there any way of flushing these files and trying again?

Thanks!

[horst]

Send a "forceNew" => true together with your images options to override existing image variations.

$options = array("forceNew" => true);
$image->width(500, $options)->url;

Or use PIAs global (sitewide) setting for "forceNew" (in PIAs module config page) and

• switch on PIAs forceNew
• just load the page(s) with this image(s) again
• switch off PIAs forceNew

[apeisa]

Same error here, after update from 2.4 client has reported problems with image uploads. These are images straight from their mobile phones (Lumia 830) and earlier (PW 2.4) uploading that kind of images has worked nicely.

Error in question is:

kuva1.0x100.jpg - not a recognized image

Clicking the broken thumbnail does show the full image. Memory limit is already 256 and the image is rather small one (554 kb).

Opening the image in Photoshop => save for web => reuploading => thumbnail creates just fine. I have the original file available, if someone wants to take a look? 

[cstevensjr]

I may be wrong but the only time I have seen that error was when I uploaded an image to a file field versus an image field.  Then when I tried to use the image in the body (CKEditor), I would get a message like that.

Edited June 24, 2015 by cstevensjr

[LostKobrakai]

I may be wrong but the only time I have seen that error was when I uploaded an image to a file field versus an image field.  Then when I tried to use the image in the body (CKEditor), I would get a message like that.

That's most likely because a file field does not handle thumbnails, which is special to images.

[Peter Knight]

I actually had this error a few times and seemed to solve it by renaming the file. I used underscores instead of dashes and that seemed to work. 

Are you sure it's an image size issue rather than a naming convention?

[apeisa]

Image is called "kuva1.jpg", so not a naming problem.

And it is definitely image field where I have drag & dropped it. Image uploads just fine, but fails to create thumbnail, and produces that weird error message.

[horst]

can you PM me the original?

[apeisa]

Thanks horst, should be in your inbox.

[Qualtext]

Hi,

i had never problems to upload images. The Server has anough memory. So huge images uploading well. But now, i have an Image from a Luma Smartphone, and this errors occurs. Argh.

If i resave this Luma-Image in Photoshop, the upload-process and croping works very well.

I test this on different Server/Webspace with Processwire 2.5 - its allways the same.

May this "not a recogniced image" fails on EXIF or META Data or specific-Data in the file like Orientation, GPS-Datas or something like this in the Luma-Image? I found nothing on websearch like this.

$additionalInfo = array();
	
$this->info = @getimagesize($this->filename, $additionalInfo);
if($this->info === false) throw new WireException(basename($filename) . " - not a recognized image");

@ https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ImageSizer.php#L260

I attach the image.

Any else have trouble with Images from (this) Smartphones?

btw: if i uploading the Luma-Image in this Forum-Thread this image will displayed. Why? May the Forum-Image-Script is the answer.

luma_image_fail.zip