Hi,

according to my post in http://www.icyphoenix.com/viewtopic.php?f=2&t=3371 I have a question.

Where can I set the maximum size a picture can have for resizing. When I try to upload a big images (2576x1932) the images is not resizing.

I use the Jupload Applet for uploading. A smaller image, for example 1600x1200 works.

It could be that you need to increase your memory allowance. Resizing very big images, and performing any other image manipulation requires a hell of a lot of memory for the large image arrays involved. You obviously need at least one other array of similar size to move 'modified' contents into, and all images are decompressed in RAM - it has to be in order to manipulate or apply resize algorithm - on your PC, the image is decompressed into RAM so you can see it. Something that might appear to only be 1MB as a jpg will occupy perhaps 30MB in RAM if it has those sort of big image dimensions - basically it will occupy in RAM whatever that file would occupy on hard disk as a BMP image, since that is uncompressed. Try adjusting php.ini, set memory limit to something like 128MB.  Just a thought...

I think at the time the original album was developed, nobody anticipated people would be uploading such large images in the first place, but now it is becoming so common with higher res cameras!

I already thought that it is a RAM problem. I changed the resize method from PHP to Jupload. Now the images are resized on client side and it work.

Ah ok, I see now why you opted for jupload! So did you get jupload to work with larger images? Sorry I haven't played with the jupload mod (although I probably will after seeing your posts), so not sure what settings needed tweaking. Sorry also for late reply, many of us are very busy at the moment, and do not check the forum as much as we'd like to!

moreteavicar wrote: [View Post]

Ah ok, I see now why you opted for jupload! So did you get jupload to work with larger images? Sorry I haven't played with the jupload mod (although I probably will after seeing your posts), so not sure what settings needed tweaking. Sorry also for late reply, many of us are very busy at the moment, and do not check the forum as much as we'd like to!

Yes my Jupload is working now but there're a few modifications before you can use it. As its implemented in the actual stable release it didn't work for me. Furtherone it works only with Internet Explorer, thats not so fine but it works. My friends often upload pictures to my site so Jupload is essential.

Yesterday I tested it with 40 Pictures at once. Each picture has a size of 3648x2736 (10 Megapixel) and it worked.

At the moment I try to implement the actual version of jupload (v0.90) in IP. It supports firefox and has a nice gui. The applet is loading but files are not uploaded. I thought the problem is the process step in but my php knowledge is not so much  

It would be great if you like to help

Help?! Possibly possibly... the problem is that Jupload was never officially ported to IP, and I suspect what is being "shipped" in the beta was originally coded for phpbb_XS (the version before IP). MG was never keen on including Jupload because of its dependence on Java, hence the lack of support here. The situation is also complicated by the fact that smartor.is-root.com has disappeared off the planet, which is where the original Jupload mod for the album was created...

I think the firefox issue you have is firefox java compatibility problems, I don't think theres anything that can be don in the php code. <--*Edit I was young, I was foolish... those were the days*... I just tried it out, the only thing that is really needed is to create a temp directory uploads/jupload (and chmod 777). Theres no need to add the extra parameters that you posted in the other thread. In fact you can make it run on the bare minimum of parameters (but must have url.action and complete.url parameters).

Another possibility I've just thought of is that there might be a space in the filename variables... during parsing, firefox does not respond very well to any names with a space in - this happened when they changed over from traditional Mozilla browser to Firefox - they dropped a lot of features in order to speed it up, but the downside is when filenames appear with spaces - in the past I've applied a fix whenever I get this problem, by appending quotes to the filename variables... I'll have another play with the code and see if it makes a difference... (alternatively test it with a nice old mozilla browser, like mozilla 1.4.1)...


BTW I obtained the latest copy of jupload from http://www.jupload.biz/content/view/12/26/
A number of modifications were required, because they have changed the name of the parameters. You also have to inlcude another 3 jar files in the template file. I got the uploader to appear to work, but it will not upload to hard drive, whether I use IE or firefox. It does not appear to respond properly to the url.action statement, even though the variables are correctly defined (it wouldn't even load if they weren't!), I don't yet understand whats going on...

moreteavicar wrote: [View Post]

BTW I obtained the latest copy of jupload from http://www.jupload.biz/content/view/12/26/
A number of modifications were required, because they have changed the name of the parameters. You also have to inlcude another 3 jar files in the template file. I got the uploader to appear to work, but it will not upload to hard drive, whether I use IE or firefox. It does not appear to respond properly to the url.action statement, even though the variables are correctly defined (it wouldn't even load if they weren't!), I don't yet understand whats going on...

That's exactly my problem. I changed all parameters and included the new jar files. Applet is loading and so on. But when I try to upload some files, the files are not processed. The message "All files have successfully been uploaded!" appears and the page is reloading (Click here to return to the category...).

I found out that the variable $file_list is empty but I don't  know how to fix it. After @set_time_limit(300); i added



With the old version of Jupload $file_list is not empty.

BTW: According to the jupload support board V0.90 will work with firefox too.

So we are not alone with these problems

The is a problem with the browsers catching/listening to the java messages and refreshing the page accordingly. The file_list variable is empty because the browser isn't being refreshed to mode=action as it should (which would then populate the file_list variable). This isn't so much a php problem but a java - browser problem.

There is a "fix" on jupload to install a javascript java listener: http://forum.jupload.biz/thread.php?sid=&postid=2930#post2930
the javascript listener class is called via their included php scripts, but I haven't spent any time yet trying to figure it out. Perhaps the easiest thing would be to try and use the scripts in the most minimalist way, without using the existing photoalbum jupload mod... just to see how it works before updating the code...

I tried the default Jupload index files - basically extract everything in the V0.90 package to its own directory, maintaining the file / directory hierarchy. You also need to chmod 777 the directory uploads and its sub directories. Run one of the html files in the jupload root directory (e.g. index.html) and the whole applet works, noth in firefox and IE (not tried konquerer yet) and uploads to the internal uploads directory.

When loading the html file, this points to the parameters file jupload.default.config which contains, amongst many things, the definition for the action url, which is to the scripts/php/jupload-post.php file. This php file is not unlike the action part of the album_jupload.php file, albeit with different variables, but it uses a "listener script" (it is misleading referred to as a javascript listener routine in the link I gave yesterday, actually it is a php class). Herein lies some confusion... on inspecting both listener class files, they essentially define a series of functions for file handling and session checking... there is no actual active script that acts as a "middle man" between java console and browser.

The reason I think the demo html files work is because the action url is to a different script page than the page that is loaded, and firefox is not good at auto-refreshing pages... so I think the way forward is to put the action and url complete parts of the album_jupload.php script into their own files and see if that helps. I'll try this with the older version of jupload first before trying out v0.9. (The older version has the advantage of smaller file size and quicker loading - although v0.9 is obviously better cosmetically)...

Well... I'm one step closer to solving the problem...

It appears that for some reason Firefox triggers a different session ID. Because the page reloads, the file_list variable is heavily dependent on storing to a global session variable (this is supposed to be handled server-side). We observe session changes by inserting appropriate echo lines in the routine, e.g. echo session_id();

In Internet explorer, we can see session id and file_list array contents during the upload action url part.

IE upload action Image:



During the  process loop (which is in same file as action loop) - after page reload, the session ID is the same, and session array contents are retrieved back to file_list array.

IE Process loop image:



In Firefox, note the session ID in action/upload mode:

Firefox upload action Image:



during process mode, the session ID is different, so the session file_list variable is lost:

Firefox Process loop image:



Why this occurs with firefox I do not yet know - possibly hosts do not allow php sessions to be stored on the server in the php default session directory (which most people say is var/), but that it is browser specific is a mystery.

Also, with simple session test scripts, the session variable appears to store ok with firefox...
...so I don't know if the firefox registers the change in php parameter (mode=process) in the URL of the album_jupload script as a new page, and therefore requests a new session / session_id...

If this is the case... and there is no obvious work around... then will need to rethink how the file_list variables are stored - most likely to SQL... *Edit SQL would slow it down a bit - much better/quicker to write directly to a file, which is precisely what server side session variable handling does*

I now have got both versions of jupload to work (V0.88 which ships with IP, and V 0.9 which is the latest). Here is some info on what I've done to get these to work:

Fix 1. There doesn't seem to be a way to solve the sessions and $_SESSION variable problem when using firefox 2.x (from searching the www it seems that this is a general problem in parsing session data from one page to another, not just related to use of jupload).

So I've created a work around. Basically if we can't trust the firefox - php server session storage - we can create our own. My approach is to create a temp file in the album_mod/uploads/jupload directory (which is also where images are temporarily uploaded) and store the file_list array to that temp file, so that it can be recalled in the process stage. Now, of course a problem arises if several users are uploading with jupload simultaneously, so I still invoke the session ID (which is unique to each browser instance), using the value of the session id to name the temp file - and also pass this value through the upload and process stages by appending it to the action.url and complete.url redirects. When the file is no longer needed in the process loop, the temp file is deleted, although if the user aborts / hits the back button during transfer, then the temp file will remain. If they choose new files, I have set up the file access to simply over-write old data stored for that session (as session id should remain unless they close browser and/or open new window to download from). This all seems to work as a pretty foolproof system, in both IE and Firefox.

Fix 2. The "death ears" browser "not listening" problem - actually the problem is more to do with the browser, mainly firefox, not refreshing a page if the redirect URL issued from the applet is directed to the same page (even with variables appended), consequently the actual upload and process routines did no get called. The solution is to move these to a single new file, which I've labeled:

album_jupload_action.php

This should be copied to the root directory along with album_jupload.php. As mentioned in Fix 1, this file is called with the session id appended to it, to ensure that the session id is propagated reliably, irrespective of browser. The session id is then used to access the temp file within the upload and process loops. I've added a few extra lines to give a more verbose output during upload, principally to ensure that the file_list variable is populated. It might seem funny that this works with two loops in just a single file - you might think the loading of the file to perform one loop means that album_jupload_action.php is now loaded, and if redirecting to the same page doesn't work properly, it shouldn't work... however. in this instance album_jupload_action.php behaves a bit like an include file, it is still being called from the main album_jupload.php page, so whenever action.url or complete.url are called, it is in the context of being called from the album_jupload.php page, (the location of the applet) so therefore it works...


I've uploaded my modded files which appear to work - with V0.9 I haven't checked fully with personal galleries, V0.88 seems to work ok, in fact I prefer V0.88 for its speed and ability to convert bmp to jpg (can't yet get that bit to work on v0.9)... At the end of the day, anything that reduces bandwitdh on the client side, and presents the user with an easy way to upload images, without them having to manipulate or edit them to fit the restraints on upload dimensions, has got to be an asset/essential. As my poor inbox and server stats can testify, many people, at the end of the day, are not gifted with common sense and are unable to grasp simple concepts like resizing and re-compressing images before hitting the send / submit button... (hence my sudden interest in jupload!)

Wow great! Very nice work. I will test it

Did it work for you?

Being curious with these issues I've had another play with how sessions are processed in the original scripts, but still couldn't get it to work as it should in firefox. I even tried starting and closing the session within each loop (technically you should do it that way) - what should happen is that when you open a session again with session_start() it should re-open the same session if it is for the same website and same browser window (until the session times out, which is of the order of 30 minutes by default), but still each loop call generates a new session. Yet on test pages that aren't even linked together (apart from having the same URL), I can still pass session variables from one page to another. How strange that firefox should trigger new sessions for different if() statements, for the same website! This has repercussions for a lot more than just jupload mod, which might be why, by default phpbb assigns session id to the URL anyway to avoid that sort of problem (although trying to avoid too much dependence on cookies also plays a part).

So I can only conclude that the above method of creating your own temp session files seems to be the only reliable way...

Happy Juploading

Yes it works great in FF and IE. Up to now I found no errors. Thanks again.

Now, im thinking about using V0.90 in my productive website because of your remark that the older release is a little bit faster.

It seems to me that the resize process is faster in the old release and this is very important because my users usually upload up to 100 pictures with a size of 3-5 Megapixels