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

____________
Luca
SEARCH is the quickest way to get support.
Icy Phoenix ColorizeIt - CustomIcy - HON

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.

____________
Luca
SEARCH is the quickest way to get support.
Icy Phoenix ColorizeIt - CustomIcy - HON

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.

____________
Luca
SEARCH is the quickest way to get support.
Icy Phoenix ColorizeIt - CustomIcy - HON

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?