Image / File Picker

[Scally_Ally]

hi all,
Been a while since I have posted on this site, but I am really struggling getting a certain section of a site working.

I have a client who wants to sell photography online, they are happy to upload all of their images via FTP. The problem occurs when the client creates a new product and tries to relate an image to it. As these images they have uploaded are so large (between 8 and 12 Mb) the website seems to have trouble serving the images in the admin system, and specifically in the file picker that I have. The user can browse files / images on the server but cant get preview.

Does anyone know of any high quality (paid for or free) image / file pickers that can be integrated with a form with a preview of the file before you choose? once chosen this returns the path of the image file?

I may have posted this in the wrong section as it will be javascript that accomplishes most of the viewable areas, but PHP for the dir scanning scripts.

Thanks in advance

Ally

[optik]

Even if there was a script like this it would be incredibly slow due to the size of these files, imo you need to make a file uploader page for the client and use imagick to make a thumbnail file for you, or even better get him to upload the thumbnail with the file, if they're a photographer that shouldn't be a problem for them.

[Scally_Ally]

Thanks for the reply but I have tried this approach.

I tried to create an image thumbnail from the large image using GD, but got memory limit issues, using shared 1and1 server. (would imageMagik use less memory?).

So then gave him a thumbnail upload file form which does all the resizing / watermarking but this option is unusable as he says he has over "50,000" images to upload so resizing all these images for thumbnails would be a pain (at that point I did try to tell him about automation in Photoshop but it went over his head).

Need to be able to display images on the server and let the user pick which image they want (all images 8Mb - 12Mb).

Will cross the memory limit issues when I have the image chosing section done.

Any help advice greatly appreciated....

Ally

[yaix2]

You can use a program like Phatch on you local PC for batch processing of images, create a thumbnail and a medium sized preview of each image and then upload everything via FTP.

[omoutop]

50000 images 8-12MB... i think that whatever approach you take your will hit server time out or something similar...

thumbs may be the only safe approach
perhaps an ftp script in your admin section that also crates a thumb of the image as it is being uploaded?

[Alcoholico]

You could use

ini_set('memory_limit', '50M');

on your image upload/resize/thumbnailing script. Increase the 50M part if that's not enough for you. It has worked before for me even on shared environments such 1&1 shared hosting.

[rocknbil]

I tried to create an image thumbnail from the large image using GD, but got memory limit issues, using shared 1and1 server. (would imageMagik use less memory?).

This is could be a permanent roadblock, I think, unless this host allows you to change the PHP limits via .htaccess.

While you can up the PHP memory limit, max file size and timeout settings either system wide via the php.ini or a per-directory directive in .htaccess, the shared host may not allow you to do so. You'll have to experiment.

Per ImageMagick: The answer is yes, it will use less memory, but this is only server-side, not on upload. If this host has ImageMagick/Imagick installed, you have a shot at it. Run a phpinfo() in your domain to see, it will clearly show Imagick and all the installed libraries for it if it is.

These file sizes are ridiculous for display in web pages (or, if they are just downloading them, good enough.) You'll need to resize them for display, and road block #2 for you is that the GD toolkit needs to reconstruct a bitmap version of the image in memory. So let's say you have a compressed .jpg you want to size to something reasonable for display. GD creates an uncompressed bitmap in memory, and this virtual file will be exponentially larger than 12 MB, maybe over 100 MB depending on the compression of the original. Add to that it still needs memory to do the resizing. Since memory is something that affects all users in a shared environment, this is why I say the host may not allow you to alter the PHP memory usage.

ImageMagick does a lot of this stuff in a virtual memory file, on disk, and seldom sucks up so much memory when resizing images, so yeah, when dealing with big images, it's the way to go. Fortunately he/she is using FTP to upload the images, you won't need to worry about the max upload sizes or timeouts, which would still be an issue if you're using a web-based uploader.

[Scally_Ally]

Brilliant thanks guys,
Alcoholico, have tried upping the memory_limit through and iniset and also through the htaccess but it didnt appear to have much effect on the shared hosting (still made the script error).
yaix2, I have tried this approach with the client but they are determined to do it through 1 image selection (and all the resizing is done from there).

The images that are 8-12Mb are only for download and and the thumbs are used for the display on the frontend of the website.

Thanks for the advice on imageMagick I will definitely have a look into this - especially if it is taking up less memory.!

Where I am up to now is I have the administrator pick the image from the uploaded (FTP) images and then have stripped out my script to run the thumbnails and process, this seems to have worked without errors but my computer illiterate client may find fault with it. I will keep you posted as this solution I have provided may not be good enough for them.

rocknbil, I think you are right that it is fortunate that they are willing to use FTP to upload the files, but the client has not given the files any kind of simple naming convention to know which image is which (strange) - but by uploading via FTP you lose the control of handling each image on the upload. And thanks for the advice on ImageMagick and how GD works..

I suppose there has to be a point where you say to the client that this just cannot be achieved, and you need to cut up some thumbnails to go with your images. Im not at that point yet but if things go wrong again I might be close to that point.

Thanjks
Ally

[lostdreamer]

Teach the client to use "MS Powertoys - Image Resizer" if using an OS < Vista, if he uses Vista or Win7 it's allready in there (I think, best to check MS site).

It gives you an option : Resize image(s) when you right click your image files.
It's one of the easiest ways to have clients create there own thumbnails in bulk, I have my photographer clients use the same and they where actually very happy with this.

Let them create 300x300 versions of their photo's to slap a watermark on and show visitors, and keep the originals safely out of the HTDOCS folder, only avaiable through your download script.

[rainborick]

I'm not sure that I understand the situation, but maybe there's a compromise or work-around solution that will work. As long as the client can upload the original files with FTP, then you could create an admin tool that would scan the directory for the image files and create thumbmail image files for each one as needed in a separate directory with the same file name. Then your admin system wouldn't have to try to serve the enormous files, the file names would be recognizable by the client (and your software), and the server wouldn't have to constantly be creating thumbnails on demand. You could have this software run automatically when the admin system is invoked, or manually via menu selection.

[rocknbil]

I suppose there has to be a point where you say to the client that this just cannot be achieved

Nah . . . there is always a way. Part of the "challenge" (for lack of a better word) of being a good programmer is understanding a client's deficiencies and/or their way of working and building an interface that works in well with what they perceive as the way to do the work. It's not always best, but it's what they need. Keep at it. :-) To wit,

but the client has not given the files any kind of simple naming convention to know which image is which (strange) - but by uploading via FTP you lose the control of handling each image on the upload.

"Naming conventions" they are just uploading raw digital camera files, probably like DSC000123.jpg or P000001234.jpg, like that. Pretty common.

So part of your scripting should involve reading the upload directory and getting a list of whatever images are there, wherever you have a view images portion in their administrative area. At this time you would also read the resized directory (or database entries, if they are recorded) to compare against. You can compare the two arrays, then output checkboxes next to images that have NOT been resized, that way they can see at a glance which images to check off for resizing and submit it all at once. If there's a database entry involved, you use this opportunity to record the file names in the database transparently. See how I just solved their problem, and made them feel smart? :-)

Clients often think what we do is "simple" because if you're good, you make it look simple. Even if it's not.