Support/Comments for Easy 2 Gallery 1.4.0-rc3

Thanks goldsky. I’ll give that a try.

For the image dimensions I’ve done a few tests and as far as I can tell it won’t accept uploads with a dimension that totals more than 5500px as described here:

http://modxcms.com/forums/index.php/topic,48471.0.html

I’ve tried several combinations of width/height dimensions (for ex: 2999x2499 and 2499x2999 works.). I used a blank image so the filesize was far below any limit (43K).

Because the mcpuck browser has trouble creating thumbnails above those dimensions, I’m not sure where the problem is anymore. Still wondering if its my server config.


EDIT: Could there be some limit like this set in GD or IM config maybe?

I increased my PHP memory limit to 64M and now I get the same error but a new line in e2g.module.class.php

Line 1054: imagefill($pic, 0, 0, $bgc);

Decrease it to 32M and it goes back to line 1043.

For what it’s worth.

Found this in the GD FAQ.

Why does gd cause my PHP script to run out of memory?
Most often, the problem is that the memory_limit parameter in php.ini is set to something very conservative, like 8M (eight megabytes). Increase that setting and restart the web server.
Of course, opening truly huge images can cause real memory problems, if several are open at once. 8,000 pixels times 8,000 pixels times four bytes for truecolor equals a walloping 256 megabytes.

How can I determine the image dimensions without loading the entire image into memory (and possibly running out)?
Very large images can cause gd to run out of memory (see the previous question). And sometimes the image file itself isn’t terribly large— consider a JPEG of a completely blank field, 8,000 pixels on a side: the file compresses well but representing it in memory as a bitmap is impractical.
If you are coding in PHP, you can check for this situation with the getimagesize function, which determines the image dimensions without using gd. This is possible because the popular image formats all store the image dimensions near the beginning of the file where they are easily accessible. Perl programmers can use the similar Image::Size CPAN module. If you are not using PHP or Perl and your language of choice does not offer a similar feature, you can implement the technique yourself. See the GIF specification, the JPEG specification, and the PNG specification.

Installing ImageMagick now to see if that works.

what is your GD version?

bundled (2.0.34 compatible)

EDIT: It’s definitely GD that’s the problem so I think you’re off the hook. I don’t suppose there is an option to use ImageMagick instead?

EDIT EDIT: NVM goldsky. I guess the problem was that I’m just a cheapskate. Upgraded RAM and set php mem limits unreasonably high. Everything works as expected now for hi-res digi cam photo uploads. Thanks for the help.

@grabenfub,
how high?

I had it up as high as 128M testing but I didn’t go too far above 4000x3000. Every image was different so I stopped getting too granular. I’ve since fine tuned it to 96M for my needs. From the equation above from the GD FAQ you can get an idea:

8000*8000*4 = 256M
4000*3000*4 = 48M

It didn’t seem to honor this equation strictly although. For the images I was using at 4000x3000 resolution it was somewhere above 64M for each one of roughly two dozen images.

ImageMagick has the same sort of equation only you can pass the QuantumDepth setting at compile time and get something like:

(QuantumDepth*Height*Width*5)/8

You can also use the limit memory flag on execution and it will switch to using I/O instead of memory at that limit, if you don’t mind the slower speed.

I don’t know enough about GD to know if it can do similar.

P.S. This may not sound like a lot to some but imagine a server with nearly three dozen sites, each with anywhere from 3-15 managers and who knows how many web users. All you’d need was some bad timing to cook up a recipe for disaster. GD could chew up 2G in memory easily.

I should also say that this is a GD problem and not necessarily an E2G problem. This could happen with that many users when the mcpuck browser tries to create thumbs out of hi-res images too. So, I’m not picking on this module. As a testament to how neat I think this module is, I’m still going to try and use it.

P.S.S. This could also be an ’I don’t have enough bread to toss at a big memory upgrade right now’ problem, just to be fair.

I can pass $_ssFile[’description’], $_ssFile[’title’], $_ssFile[’id’], etc. But how do I pass the tag and summary fields in a slideshow index?

I’ve tried $_ssFile[’tag’] and $_ssFile[’summary’] but they don’t work.

ow... I haven’t listed them.
I’ll make an update on this matter.

I was going to try and use the tag field to link the big image link to a URL was why I was asking actually. So instead of getting the big image when they click the slideshow picture, it takes them to a page on the same site. I’ve tried landing page but I need a separate URL for each slideshow image. I’ve got it working using $_ssFile[’title’] and then naming the picture the same name as a friendly URL.

I’m thinking I could add a field called URL or something to the db in easy2_files. Although, I’m not sure how to get that from there to here so to speak when it comes to calling it in a slideshow index.

On another note some of the description calls in the slideshow index are wrapped in p tags. The description field tiny_mce editor adds its own p tags on save which results in nested p tags if you enter a description.