Bug when SLIR cropping size is the same size as original images

[o-l-e]

I am experiencing a nasty bug, when i try to set the image cropper to the same size as the original image.

If my markup looks like this:

<img src="{{resize_path(image.url, 2048, 2048, 0, 95)}}" />

and my original images are 2048 x 1536 px, they don't render at all.

Could it be because SLIR doesn't know what to do with the image, or some other reason?

[kolber]

Hey @o-l-e, that is an interesting bug. It is definitely a SLIR-specific thing though. Have you tried getting in touch with the SLIR developer about it?

[o-l-e]

@kolber i have posted an issue on the SLIR pages about it, so please back me up if it gets too technical for me ;)

[mjau-mjau]

can you please try the following, and tell me what result you get?

<img src="{{resize_path(image.url, 2000, 2000, 0, 95)}}" />

[o-l-e]

@suncat100 still nothing i'm afraid.

[mjau-mjau]

But then doesn't that prove that the problem is NOT that the image cropper is set to the same size as the original image? In fact, this problem is related to the memory usage of PHP when resizing images ... You will see that if you further reduce those numbers (2000, 2000), you will find that at some point it will actually work (obviously). Somewhere in there, is the threshold number for what you can resize to ...

You can experiment directly in browser, just get the rendered SLIR path something like this:

http://domain/render/w1700-h1700-0-q95/4.gallery/image.jpg

In my testing, the above works for me, but the below does no. It may not be the same for you, depending on your server and the image ... you might need to reduce the number further.

http://domain/render/w1800-h1800-0-q95/4.gallery/image.jpg

SLIR uses the GD library, and this library has requirements on the memory available on your server, which will affect what renders sizes you can deal with. This is entirely normal behavior by the GD library, and is not related to SLIR. In fact, I even checked the error in my php log:

[18-Sep-2013 05:05:59 UTC] PHP Fatal error:  Allowed memory size of 29360128 bytes exhausted (tried to allocate 8204001 bytes) in /***/selfy/app/parsers/slir/slirimage.class.php on line 632

[o-l-e]

Thanks @suncat100 for the feedback. I guess i should look to upgrade my server :)

[o-l-e]

Reopening this since i found out it wasn't a server issue, if it is ok. I tried using images that are much larger than 2048, and it worked fine (no larger than 4-5mb size). Seems really strange, and can't really see the logic to what causes the bug.

Anyone else having similar issues?

[mjau-mjau]

It is related to the image size you want to create not from the size of the image you want to create from ... Therefore it does not necessarily matter if the original image is bigger, as it still be able to create the image. So with your new images (larger than 2048), are they resizing nicely to 2048 now?

<img src="{{resize_path(image.url, 2048, 2048, 0, 95)}}" />

Keep in mind this is related to server memory, but also the physical attributes of the image. There is definitely going to be a limit to what size images you can dynamically render with PHP+GD, this is just a fact.

[o-l-e]

@suncat100 i simply don't understand it myself. I have uploaded a 2048x1536 and the cropping setting is 2048x1536 (with quality setting 95 for reduction). What happens is that it won't render.

I don't know much about the php, but if you have a look at this post https://github.com/kolber/stacey/issues/88 i have managed to reproduce the same as here using other image, also using a previous version of stacey 3.

[mjau-mjau]

Your server simply is not able to process an image that large (2048)... Simply try reducing both numbers, and you will plainly see at some point that it will work ... It will not work though by increasing the numbers ... Isn't that a clear indication that its related to the image size parameters? Also, it can be related to both the original image size and the designated render size in combination.

I have seen your other issue, and not quite sure what you are saying. It seems you have used the same settings before, but that may be irrelevant as it depends on the input image (size, aspect etc) ... for all I know, your server could have been set to use more memory before ...

I have worked on a project with the GD library (which SLIR uses) for several years, and the fact is that it simply is limited by server memory ... I have tested with SLIR and cannot see any SLIR-native errors. The size of the numbers you throw into the SLIR function are imperative, as well as the size and aspect of the original image.

[o-l-e]

ok, thanks for the feedback @suncat100, i will close this again.

Regarding my other issue, my point was that it worked fine with an original image that is 1536px x 2304px. The server has the exact same settings, and i even installed both apps and tried the same on both servers.

But, i trust you with your experience and keep up the good work :)