coldfusion MSFT SQL Image Store - sql

I am using ColdFusion 10 and working on new project where the user will be allowed to upload pictures from events. Never worked with user uploaded images before. How do I store the image in MSFT SQL? Is there a best practice when it comes to users uploading huge 10 MEG pictures? Is there a way to control or automatically compress pictures?
Thanks!

This is a two part question:
Part 1:
First part will be your data store and pull. Where you will use in your cfquery, cfqueryparam that will look like this:
INSERT into EMPLOYEES (FirstName,LastName,Photo)
VALUES ('Aiden','Quinn',<cfqueryparam value="#ImageGetBlob(myImage)#" cfsqltype='cf_sql_blob'>)
To select then reconstruct you will use this:
<cfset myImage = ImageNew(#GetBLOBs.PHOTO#)>
Where you can then do this:
<img src='#myImage#>
Above examples pulled from the docs.
Get familiar with <cfimage> and cfscript version image() for editing (rotating, scaling, etc.)
Part 2:
The other part to your question has to do with upload limits.
Coldfuion has limits that can be changed in CFIDE or RAILO equivalent. There is also limiters set in your web service like apache and IIS, you will have to look into this to change it.
BUT if you are only concerned about 10 mb size images you will be fine. It is when you get into hundreds of MB size files that will cause you headaches.
Remember on your form to set your form enctype to this because you will have to upload your file to your server before you can work with it:
<form action="workPage.cfm" method="post" enctype="multipart/form-data">
Also you will have to access that file using <cffile>
I think all this is enough to get you started.

If you are concerned about the storage size of an image, and this is of course a reasonable concern, then you could use to scale the image down to the maximum dimensions and quality or compression level (if stored as a jpeg) that you need within your application.
Storing your images within a database allows them to be more easily portable, across a cluster for instance. If that is not a concern, then what I tend to do is generate a unique name for each image uploaded, rename them, and store the unique name in the database rather than the image itself.

Related

Reduce image size of multiple images via ssh

I have an e-commerce website I made for a client.
As with any e-commerce site, there are a lot of pictures.
About a hundred of these pictures were uploaded by me, provided by my client.
The other 400 were uploaded by client.
The problem is that the first set of images that my client provided me with were about 100kb each, which is not such a big deal. The second set of images, the ones my client uploaded, were about 5-9 MBs in size. Obviously I didn't see this until it was too late.
So my question is this: How can I reduce the image size of all those load-heavy images to something more around 100-200kb through ssh/commandline/php.
I'm also talking about re-scaling the images to something smaller (currently they are about 3700px x 5600px).
Please note: I don't need a solution to re-scale the images when they are being uploaded.
I need a solution to re-scale the images that are already on the server.
Assuming your server is a Unix, you can use imagemagick/convert tool:
http://doc.ubuntu-fr.org/imagemagick
You can also use PHP+GD, see:
http://fr.php.net/manual/en/book.image.php

Download large amount of images with objective-C

I'm currently developing an order entry application for my company. This means I need to download approximately 1900 product images to the iPad, and that's just the normal images. I also need to download an equal amount of thumbnails. The reason for downloading the images to the iPad instead of just displaying them from a given URL is that our reps wander into large stores which often don't have stable internet connections.
What would be the best course of action? The images are stored on our servers, but you need to be authenticated using Basic Auth before you can access those. I have thought of just downloading them one-by-one, which is tedious, or group them together on the server as a zip-file but that would be a large file.
A one-by-one is a valid options for the download. I have done projects with similar specs, so what I advise:
Use some 3rd party library to help you with the download of the images. MKNetworkKit for example. If you feel confortable enough, NSURLConnection is more than enough.
Store the images in the application sandbox.
Instead of downloading the thumbs, just create them on the go when you need them (Lazy pattern). Unless your image's thumbs are somewhat different than the original (some special effect).

Best to open many files as you go or all at once

Windows Form Application vb net
I have many container files on a hard drive, inside of them are many images. I have to get a particular image by using an ID to do this I have to go trough each of the container files and find the one which has the ID in it then I can retrieve the image.
I think I have 3 options:
load all the images at start up into memory, some images may or may not be used.
as I need each image go through all the container files and open the image into memory.
create a dictionary of IDs and what file they are in at start up and then get each image as I need it without have to go through all the container files.
Which option is better in that there is less delay between the user asking for the image and the image being shown, but doesn't use too much memory or slow downthe computer
(average computer memory of the users who would use thisapplication is about (2-)3-4GB
Does the location of the images in relation to the container file change over time? If not, one option would be to have a one-time operation that will index the files and write this information into a separate file. This index file could be loaded at startup, and then your code would know in which contaier to find a particular image.
The amount of memory on user computer is not that important - this memory is not yours and it's the user that decides how to deal with that memory. Your task is to find proper balance between memory consumed (try to keep it minimal) and speed of operations.
The choice will depend on the number of containers and the number of images in each container.
If the number is small, load everything to memory and don't bother.
Dictionary of IDs is the preferred "generic" way, when the number of containers and files is unknown.
There's one more thing to think about -- how are IDs generated AND stored? For example, if containers are named AA to ZZ and image IDs are numeric, then you could store references as "BS123", which, when you need an image, will tell you to open container BS and take image 123.

iPad - how should I distribute offline web content for use by a UIWebView in application?

I'm building an application that needs to download web content for offline viewing on an iPad. At present I'm loading some web content from the web for test purposes and displaying this with a UIWebView. Implementing that was simple enough. Now I need to make some modifications to support offline content. Eventually that offline content would be downloaded in user selectable bundles.
As I see it I have a number of options but I may have missed some:
Pack content in a ZIP (or other archive) file and unpack the content when it is downloaded to the iPad.
Put the content in a SQLite database. This seems to require some 3rd party libs like FMDB.
Use Core Data. From what I understand this supports a number of storage formats including SQLite.
Use the filesystem and download each required file individually. OK, not really a bundle but maybe this is the best option?
Considerations/Questions:
What are the storage limitations and performance limitations for each of these methods? And is there an overall storage limit per iPad app?
If I'm going to have the user navigate through the downloaded content, what option is easier to code up?
It would seem like spinning up a local web server would be one of the most efficient ways to handle the runtime aspects of displaying the content. Are there any open source examples of this which load from a bundle like options 1-3?
The other side of this is the content creation and it seems like zipping up the content (option 1) is the simplest from this angle. The other options would appear to require creation of tools to support the content creator.
If you have the control over the content, I'd recommend a mix of both the first and the third option. If the content is created by you (like levels, etc) then simply store it on the server, download a zip and store it locally. Use CoreData to store an Index about the things you've downloaded, like the path of the folder it's stored in and it's name/origin/etc, but not the raw data. Databases are not thought to hold massive amounts of raw content, rather to hold structured data. And even if they can -- I'd not do so.
For your considerations:
Disk space is the only limit I know on the iPad. However, databases tend to get slower if they grow too large. If you barely scan though the data, use the file system directly -- may prove faster and cheaper.
The index in CoreData could store all relevant data. You will have very easy and very quick access. Opening a content will load it from the file system, which is quick, cheap and doesn't strain the index.
Why would you do so? Redirect your WebView to a file:// URL will have the same effect, won't it?
Should be answered by now.
If you don't have control then use the same as above but download each file separately, as suggested in option four. after unzipping both cases are basically the same.
Please get back if you have questions.
You could create a xml file for each bundle, containing the path to each file in the bundle, place it in a folder common to each bundle. When downloading, download and parse the xml first and download each ressource one by one. This will spare you the overhead of zipping and unzipping the content. Create a folder for each bundle locally and recreate the folder structure of the bundle there. This way the content will work online and offline without changes.
With a little effort, you could even keep track of file versions by including version numbers in the xml file for each ressource, so if your content has been partially updated only the files with changed version numbers have to be downloaded again.

Is storing Image File in database good in desktop application running in network?

I recently came across a problem for image file storage in network.
I have developed a desktop application. It runs in network. It has central database system. Users log in from their own computer in the network and do their job.
Till now the database actions are going fine no problem. Users shares data from same database server.
Now i am being asked to save the user[operator]'s photo too. I am getting confused whether to save it in database as other data or to store in separate file server.
I would like to know which one is better storing images in database or in file server?
EDIT:
The main purpose is to store the account holder's photo and signature and later show it during transaction so that teller can verify the person and signature is correct or not?
See these:
Storing images in database: Yea or nay?
Should I store my images in the database or folders?
Would you store binary data in database or folders?
Store pictures as files or or the database for a web app?
Storing a small number of images: blob or fs?
User Images: Database or filesystem storage?
Since this is a desktop application it's a bit different.
It's really how much data are we talking about here. If you've only got 100 or so users, and it's only profile pictures, I would store it in the DB for a few practical reasons:
No need to manage or worry about a separate file store
You don't need to give shared folder access to each user
No permissions issues
No chance of people messing up your image store
It will be included in your standard DB backup
It will be nicely linked to your data (no absolute vs. relative path issues)
Of course, if you're going to be storing tons of images for thousands of users, I would go with the file system storage.
I think you have to define what you mean with better.
If it is faster my guess you don't want to use a database. You probably just want it plain on a file server.
If you want something like a mini-facebook, where you need a much more dynamic environment, perhaps you are better of storing it a database.
This is more a question than an answer, what do you want to do with the pictures?