Icy Phoenix

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

Glad it works! Wow thats a lot of images from a single user! Hehe, I only ever tested with about 5 images!

The speed issue is more related to page loading - at least that's as far as I've observed - which can be expected because of the size of the jar files in V0.9 (and the fact there's 3 of them!). Once jar files are downloaded, they should remain in the java runtime cache until the user deletes it (or cache runs out of memory). So theoretically speaking, once the java is cached, it should be quick to load... however, if users are likely to be uploading from internet cafes etc, then the jar files would be downloaded each time, and that could be a real pain! I have also noticed that if I have a lot of browsers and tabs open in firefox, V0.9 does tend to respond slower to mouse clicks, but obviously a bloated firefox doesn't help, and I don't think many people have open sessions with 100 tabs or more!

I think as far as actually resizing images goes, I would have thought they used the same algorithms (in fact they are fairly generic - e.g. a bicubic algorithm is a bicubic algorithm, it doesn't have alternative methods to achieve the same results - See here if you're interested). Actually this brings me to the next point - resize image quality - ask yourself it it matters if these images come about a bit "blocky" or jagged, or do you want them to still look high quality... As mentioned in my notes, I've set the default compression to Bicubic, which is the best quality resizing algorithm, but as a consequence is slightly slower (not sure by how much, obviously depends on the CPU of the client / user). To get the resizing to work faster you can set the algorithm to none, but this leaves the blocky/pixelated edges. I guess the real way is to try uploading 20 images and time it for both methods (or time it as far as resizing goes - actually timing uploads to your server for comparing is unreliable, due to fluctuations in server load, unless you don't mind doing it a large number of times to improve the statistics!).

Thus it all ultimately depends on end user. It sounds to me like V0.9 would be best for you if you want a good quality/professional appearance (and it can be skinned, although I've not looked into that), but as said... if using internet cafes or slow PCs... and the other thing I mentioned before - V0.88 has the ability to convert bmp to jpg on the fly - V0.9 doesn't seem to work - there are some occasions where that can be useful. Well perhaps you could offer both versions so the user can choose which to use depending on their circumstances. All you need to do is rename the files for one of them to something else, like jpload2.php, album_jupload2_body.tpl, and the link to the template needs to be updated in jpload2.php - you look for the line:
and replace with The action file should work regardless of which java page was loaded, so no need to rename them. Obviously you would need to add buttons/links for both versions, with maybe some explanation by them. If I remember, the template files to modify the buttons in are album_cat_body.tpl and album_personal_body.tpl. You can modify these just like a html file (but as you will see they also include some code / variables created in the php pages) - anyway its not hard to control layout in the templates if you know some html. Of course you may already know how to do it, so I'll shut up now

** Topic moved to FAP Gen Discussions and Customisations <--Note that is the proper English spelling, not American... hey Artie **

I think you it could be right that the resize speed depends on the algorithm. The speed of loading the page is not the problem, all users use a boardband connection and only upload from their home pc.

In my old jupload version resizeInterpolationAlgorithm is set to "none". So that could be a reason why its faster - I will check.

However the algorithms jupload offers are not the best. A few days ago I resized a image in 16:9 format, and the quality was not very good. On the other site I test it with the freeware xnview and laczos algorithm and the result was perfect. Unfortunately laczos is not supported by jupload.

Ah yes, broadband does not necessarily mean fast (ultimately your server load is the limit - if a shared server via the typical hosting package, actual data transfer could be less than 100 kbps! None-the-less if they are using the same machine then that is ok.

With regards to algorithm, sometimes it depends on how small you're reducing to, there are some circumstances where bilinear actually gives goods results, and it is only when enlarging the image that a decent algorithm is needed... On other image manipulation packages I've not seen any observable difference between laczos and bicubic (maybe just my display, though it is 1600x1200 res), especially in reducing, although in theory laczos should be better - its all down to experimentation of course. In the V0.88 files that I uploaded, I set this to bicubic - actually I didn't see a major difference in speed from none, although perhaps thats only because I tried a small number files at once. The results were still good though...

Anyway happy tweaking... hope all these images are legal

Re xnview - this looks good - might be a case for trying to hack the scripts and use that instead! Nope its not a java module!...

moreteavicar wrote: [View Post]

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...

JUpload has been integrated some months ago... but I've never added a link, because it wasn't working properly...

If you look at IP files you will notice even album_jupload.php

Mighty Gorgon wrote: [View Post]

moreteavicar wrote: [View Post]

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...

JUpload has been integrated some months ago... but I've never added a link, because it wasn't working properly...

If you look at IP files you will notice even album_jupload.php

Indeed we know this MG, but if you read the last few posts you will see some random guy made a fix for it, so now it does

Sorry I missed the attachments...

I will test them.

Thanks.

Niente, mighty cheese

BTW Do you know what happened to Smartor's site?

I guess Smartor decided to remove it when phpBB 3 became GOLD just to not be bothered to upgrade his mods... but it's just a guessing... I didn't talk to him.

Jupload does not finish oploading when uploading bigger ammounts of files, it just stops, doesn't give any error, i use my own php upload post scripts, the files are converted to a smaller size first and upload afterwoods, i create the thumbnails with my own php scripts, using GL libraries, if you need to see those scripts, tell me plz

patch wrote: [View Post]

Jupload does not finish oploading when uploading bigger ammounts of files, it just stops, doesn't give any error, i use my own php upload post scripts, the files are converted to a smaller size first and upload afterwoods, i create the thumbnails with my own php scripts, using GL libraries, if you need to see those scripts, tell me plz

Hello Patch, thanks for posting here. The problem you are having is to do with your JRE runtime environment - it may have run out of memory, as sometimes happens, especially if there are other java applets running at the same time. Jupload V0.9 apparently has slightly improved mehods for handling variables in JRE, so you could try that version to see if it helps. I've personally not run into any problems though.

As for php converting file sizes, I think you miss the point of how php works.
Php is server-side. This means all remote data has to be parsed to the server in order for it to be processed - a server simply cannot resize a file without that entire file being uploaded to it. I suspect if you disable all the image resize functions of the script and observed the resultant saved file size, it will be the same as the original file size on the client, meaning that all you have done is transferred a file from point A, the client, to point B, the server. You just cannot resize a file client-side in anything other than java - which is the reason why these apps exist in java. (And why not javascript - there just isn't the capability for it - and if you could, you'd be uploading data to the browser and expecting the browser to perform the file manipulations - hardly a reliable method - but there is not even a way to upload a file to the local browser in javascript - the upload object is for uploading to a server, let alone image libraries to preform the resizing). By all means share your programming ideas though, as I'm sure it'd be interesting to compare to FAP. I'm also surprised to see you say you're using GL libraries - do you not mean the gd libraries?