Warning: imagecreatefromjpeg():

[cuzoki]

This is the error I get:

Warning: imagecreatefromjpeg(): './albums/edit/mHTTP_temp_80926eca.JPG' is not a valid JPEG file in /homepages/38/d94897174/htdocs/photo/include/picmgmt.inc.php on line 202

This didn't happen a few days ago when I upload. If you think it has something to do with the php version I'm using or something like that please let me know. I am using 1&1 internet hosting and I did not find the version numbers. Thanks.

[Joachim Müller]

use phpinfo from the admin tools in coppermine admin menu to find out about your php version.
There's a known issue for some users (very few actually), where the edit folder inside the albums folder gets deleted. Use your ftp software to create a sub-folder in coppermine's albums directory and CHMOD similarly to your albums folder (755 or 777, depending on your server config). Please search the board for details.

GauGau

[cuzoki]

Thanks for the reply. The edit folder is still inside the Albums dir. My php version is 4.3.6. I chmod everything to 777.

[Joachim Müller]

Please post a link to your site and a test user (non-admin with upload permission) to check.

GauGau

[kerry]

I'm having the exact same problem.  I just switched servers and upgraded to 1.3 from a previous version of coppermine.  I thought everything was working fine until I tried to upload a photo.

Here's the interesting part:  the host I switched to is 1 and 1.  Just like the OP.

[cuzoki]

Here is the site and account information. As I said this didn't happen a few days ago. Could be 1&1's problem. Thanks for the help guys.


Site: http://tdash.us
User: tdash
Pass: tdash

[cuzoki]

I have noticed something. It doesn't give me an error if the picture size is 640x480. I don't know if it's the format of the picture or maybe it has to do with the actual size(as in memeory.) The pictures I was trying to upload are taken from the same camera.

[cuzoki]

I searched online for the  imagecreatefromjpeg() and I found that it seems to be having problems handling anything abouve 400kb for some people. I did not find any way to fix this though.

[Joachim Müller]

there's something fishy: the link you posted points to a 4images gallery, not to a coppermine gallery. You either have given up working with coppermine and started using 4images, or you are looking for support on the wrong place at all.

GauGau

[cuzoki]

Oh I gave you the wrong link, I was testing both of them at the same time. It does the same in 4images though. Read this reply E-mail from 1&1.

Dear XXX, (Cust:@%@^$E)

Thank you for contacting 1&1 Internet.

Imagemagick is not installed and there is no way to get it installed on the server.
Unfortunately we do not support GD

If you have any further questions please do not hesitate to contact us.

--
Sincerely,
Kevin Scanlon

Sort of odd since GD is partially working, but I guess they just don't support it.

[Joachim Müller]

use phpinfo to find out about the GD version on your server (refer to the FAQ how to do that). If you have neither ImageMagick nor GD, you won't be able to use coppermine at all, sorry.

GauGau

[kerry]

cuzoki hasn't responded yet, so I will.  My site hosted at 1&1 (like cuzoki's) tells me that gd support is enabled with a version number of 2.0 or higher.  Here's the relevant section:

Code Select Expand

gd
GD Support enabled
GD Version 2.0 or higher
FreeType Support enabled
FreeType Linkage with freetype
GIF Read Support enabled
GIF Create Support enabled
JPG Support enabled
PNG Support enabled
WBMP Support enabled

Other discoveries:  I can get it to work if the image is small enough, but it has to be much smaller than the settings in the config.  With the same image, if it is sized at 1300x997 pixels, 164 KB, it works.  If I size the same image at 1400x1073, 184 KB, it gives the error.  The config is set at 1024 KB max file size and 2048 pixels for the max width or height.  Am I missing something?

Thanks for the help.

[kerry]

Doubling the sizes for uploaded files (2048 KB and 4096 pixels) doesn't change anything.  The 1400 pixel file still fails.

[Joachim Müller]

setting the max resolution in coppermine to a high value is just wishfull thinking if your server is set up to support only a special resolution. You are recommended to read the stickies before posting, this is all explained in detail on the sticky thread General Upload Troubleshooting. Remember you can't change php.ini's settings if you're webhosted, so you'll only be able to use the max resolution your webhost has set up for you in php.ini. Allowing such ridiculously large dimensions is not a good idea at all, since it's an extreme waste of resources and disk space.

GauGau

[dncohen]

I'm happy to see this thread because I'm experiencing the exact same problem.  I'm also hosted on 1 and 1, unfortunately.  The problem occurs only when the jpeg image is larger than a certain size, either in bytes or pixels I'm not sure which.  And I'm not sure exactly what the threshold is.

I'm not sure I understood GauGau's last reply.  What's a sticky?  All those upload settings have to do with getting the file to the server in the first place, right?  In my case, the file is certainly getting there.  I see an error like like cuzoki's, then I check the file mentioned in the error, its the same size as the file I intended to send, and if I FTP it back to my machine, it displays fine in every JPEG viewer I have.  So the file seems to be making it to the server OK.

Am I missing something?

To see my phpinfo, check out  http://yogadex.org/test.php.  To see my Coppermine 1.3.0, check out http://yogadex.org/photos

And thanks for any help!

-Dave

[Joachim Müller]

a "sticky" is short for "sticky thread": those threads are at the very beginning of a support board, with a pin icon (they have been sticked at the top). This way, supporters are highlighting important threads that users should read first before posting to the board. In your case, this doesn't even matter, as I posted a link to the sticky in question as well.
It appears you haven't read the sticky, or you had a problem understanding it: if you're webhosted (and apparently you are), there are some settings that apply for your server that can't be changed by you (only your webhost 1&1 can change them). One of this settings limits the max resolution your pics can have, another setting limits the max filesize your pics can have. As you're webhosted, you can't change this settings, so you will have to live with those restricitions. In other words: you can't upload files that are bigger than xxx bytes or have a resolution that is bigger than xxx by xxx pixels to your server. Exclamation mark. On most webhosts, those limitations exist for a good reason: allowing higher filesize won't help you and would still resources and bandwidth from the server (on which other users are hosted as well). For most webhosts (including 1&1), the limits are that high that you're even recommended not to upload files that are a little lower than the limits, but you're meant to resize the pics on your client before uploading to a decent size anyway.

Hope this clarified things for you.

GauGau

[dncohen]

GauGau,

First thanks for bearing with my newbie question.  It's easy to get to the support forum and search for say "imagecreatefromjpeg" and be shown lots of threads, without ever seeing a sticky thread or being told to read them.  That's what I did at first, but now I'm caught up.  So back to the topic at hand...

When you say, "One of this settings limits the max resolution your pics can have," are you referring to memory_limit?  Using a formula from one of the sticky threads, I believe my image, which is 2272 x 1704 pixels, could require 14M of memory.  (Yes its large but I'd like to upload it anyway).  So now I want to know how big is my memory_limit - and this gets a little confusing as I'll explain.

If I view phpinfo from within coppermine (http://yogadex.org/photos/phpinfo.php), I see memory_limit set to 40M.  This surprised me because a similar file in my sites root directory (http://yogadex.org/test.php) shows memory_limit set to 8M.  Does coppermine somehow set the limit to 40M???

Also, the sticky thread I mentioned earlier (http://forum.coppermine-gallery.net/index.php?topic=5843.0) states that you cannot change memory_limit with ini_set().  But php.net seemed to say otherwise so I tried this: near the top of upload.php I added "ini_set('memory_limit', '500M');" and near the bottom I added "phpinfo();"  Together these changes allow me to see that memory_limit has a Local Value of 500M and a Master Value of 40M while in upload.php.  So I'm a little uncertain what my memory_limit really is, but if I believe the phpinfo() call from upload.php it should be large enough.

Even with these settings, I see the same warning as before:
Warning: imagecreatefromjpeg(): 'albums/userpics/10001/dave_sharath~5.jpg' is not a valid JPEG file in /homepages/32/d91926016/htdocs/photos/include/picmgmt.inc.php on line 202
and the failure message:
The previous file could not be placed.

And again if I look at the file, 'albums/userpics/10001/dave_sharath~5.jpg' it is of the correct size, so it seems to be uploading fine.  But when coppermine tries to create a thumbnail the warning is produced and later the failure message.

Do you think memory_limit is the issue or could it be something else?

Thanks as always for any help.  I do appreciate it.

-Dave

[Joachim Müller]

Dave,

a resolution of 2272 x 1704 pixels is ridiculously large for any web application; it's a waste of resources to resize such a pic on the server (instead of resizing it on the client before uploading). Storing it as full-size pic on your webspace is a waste of webspace as well, and enabling users to actually see the full-size and download such a huge file is a waste of bandwidth and time (I wouldn't wait for such a huge file to be downloaded, although I'm on broadband). I'm not trying to make you look like a fool, I just want to point out that the whole approach isn't right: 1&1 have set up limits that make sense imo, even trying to overcome them is pointless.

OK, back to your question: coppermine does not manipulate server setup, so it's hard to imagine that coppermine's phpinfo.php should display other values than a plain <?php phpinfo(); ?> command in any file on your server.
It hard to tell if your manipulations with ini_set will have an impact, as it's up to the server admin again to allow overrides or not. Allocating 500 MB memory to one process on a shared host is definitely a no-no and will get you in trouble with your webhost sooner or later.

Do you think memory_limit is the issue or could it be something else?

Yes and yes: could be memory limit or another issue. As I said above: I wouldn't bother, I just don't upload so large pics, even on the servers that are mine to administer.

GauGau

[JeWelz]

Hello GauGau,

I'm experiencing the exact same issue as dncohen and I was hoping that the answer to his last question would provide more insight to the issue.

I've read several posts where you've repeated your stance on uploading large files and having them resized on the server.  I understand where you're coming from when it is simply for gallery use - and I agree. 

However, I plan on using Coppermine for a stock photography site where users can purchase and download high resolution photos for printing purposes.  And as far as resizing on the client, I want to provide a service to photographers and resize the photos for them (for two reasons - convience for them and consistancy for me). This leads me back to asking the same question that dncohen has asked.

Could you provide some possible hints as to what we could do to trouble shoot this issue any further? 

I know that it is possible to resize 50MG files on a server but I don't know if it is a sole limitation of my server configuration (which you seem to indicate it probably is) or if it could also be a limitation of PHP/GD that is currently preventing me from doing this. 

Is it possible its a difference between using Image Magick vs. GD??

Any further guidance would be greatly appreciated!!!

Thank you!
Julie

[Joachim Müller]

you will definitely need a dedicated server for this, not a shared hosting environment, as the server has to be specifically set up to stand such a load. I strongly recommend having a professional help (someone who really knows server administration) with such a setup.

Joachim