I have an application where users upload an image and it has to be available in three different sizes (thumbnail, medium size, full size). The image does not need to be modified by my users.
It seems there are two options:
Option 1:
Use image conversion urls whenever I want to display a thumbnail.
Ex. https://www.filepicker.io/api/file/hFHUCB3iTxyMzseuWOgG/convert?w=200&h=250
Option 2:
Use convert() with store to store the thumbnail in S3.
My question is can I use Option 1? How would this impact performance? Are the converted files cached on filepicker.io's end or does filepicker convert the image every time the user's browser hits the conversion url?
The converted files are cached on our end, so using the conversion urls is entirely supported. If you know the sizes that you want ahead of time and don't think you'll need the variety, you can also use the .convert() call to "precache" the conversions, but it's more of a style preference than a huge performance difference
Actually, there is a very important difference between using the Javascript .convert() method and using the /convert REST url.
Each time you call .convert() you use up one of the upload credits in your account, whereas using the /convert url method uses one of the conversion credits... and accounts have a lot more conversion credits than upload credits.
So, where possible, using the /convert url is significantly cheaper.
Related
I looking for the best way to upload an image from mobile phone to my server. I am currently using html5 to open the camera and take the picture, then I convert the file into a base64 string, then I send to the server, then save it in MongoDB.
I am expecting around 1000 to 1500 user request per day ( upload image ) , so I have the following question :
Is it a good way to do it?
Should I compress the base64, if yes how?
Should use a specific server to handle this task?
My backend is node express and the front end is ReactJS.
Thanks
It all depends on your situation. Reading and writing images from a cdn via i.e. streams is usually faster than reading and writing binary representations of images i.e. base64 from a database. However, your speed if reading from a cdn will obviously be effected by what service you use. Today, companies like Amazon can offer storage to a very cheap price so if you are not building a hobby app for like a student project you can usually afford it. Storing binary representation of images actually end up a little bit bigger in size than storing the image itself. You don't compress the base64, you compress the image before converting it. However, if you can't afford a storage account and if you know your users won't upload that many images it is usually enough to store binary representations of the images in a database. Mongo Atlas, for example, offers 512 mb for free on their database clusters. Dividing tasks of your app such as database requests and cdn services from your main application is usually a good choice if possible. This way you will divide the cpu, memory, etc. of your hardware and it will lead to faster reading and writing tasks for the user.
There are a lot of different modules for doing this in node. JIMP is a pretty nice one with loads of built in functions like resizing images and converting them to binary, either as Buffer or base64.
I am creating a RESTful web service and some of the resources are computing or processing functions. For instance, it is possible for a user to scale and convert images through the API by submitting an image and receiving the scaled or converted image back.
According to the RESTful Web Services Cookbook, section 2.5, I should use GET:
Treat the processing function as a resource, and use HTTP GET to fetch a
representation containing the output of the processing function. Use query
parameters to supply inputs to the processing function.
This is clear for cases where the inputs are simple (such as the long/lat coordinates of a point). However, should I follow the same advice for larger inputs such as images? As far as I know it is not possible to send this much data as a query parameter.
Use POST. In effect you are doing an Image Upload and processing on the server. Can't think of another way to do it unless the image is already stored on the server.
The image is a resource. Use PUT to put the resource on the server, then GET the resource, supplying parameters indicating your desired size.
Due to protocol limitations on HTTP I advice against it. This is a very valid very viable example of an exception that should be made to this rule.
Check out this link http://support.microsoft.com/default.aspx?scid=KB;en-us;q208427. It says that the maximum URL for IE is 2083 characters
This is my first question so I will do my best to conform to the question guidelines.
I am developing an iPhone app that parses and XML feed to be displayed in a table. Parsing is not a problem but I am not sure of the best way to optimize loading times after initial run of the app.
Here is the different approaches that I am considering:
Parse the XML feed each time the application is loaded. Easy way but possibly longer loading time each run of the app.
Grab the feed and store it locally (as .xml) then parse locally. Then, each time the app is opened, make an http call to see if the feed has been changed. If not, parse locally. If so, download the new feed and parse locally. The initial loading time will be longer but could be cut down on later runs (if the feed as not been updated). This option will be beneficial if the user has a bad signal but needs to see the data.
Parse the feed and store it into a local sqlite db. Then, each time the app is opened, make an http call the see if the feed has been changed. If so, detect which objects have been added/removed and alter local db accordingly. If not, load data from local db. This might be the best option but I am not sure how long finding the changes will take.
My feed is only about 100 or so items, each with roughly 20 fields.
Initial parsing time:
Roughly 4-5sec with full bars.
Roughly 5-7sec with 3 bars.
Any insight as to which option would work best would be very much appreciated.
I think the frequency of the xml data changing should be a factor. If its only going to change once a day/week? Id load it, save it, and check for updates. If update exists download new and overwrite old.
Third solution is clearly the best and it will allow your app to work offline and start quickly. To detect the change, you can simply store a MD5 of the xml file in database and match it against the MD5 of the new XML file. If data has changed, then simply discard all previous data.
I need help with downloading from webserver...
What i currently do is get XML file from web servers that contains image locations, parse XML, download each image, store image on iphone, and store image name to sql database.
This takes lots of time because there is large amount of images to be downloaded and i am downloading one by one.
My app update just got rejected because reviewer decieded that downloading is too long... What is funny, last two updates passed without problems..
I was thinking about zipping those images on server and sending zip file to iphone, unzipping it there, or packing images together with binary and sending it to apple.
Any advice on how to make download faster, would be appreciated. Thanks.
BTW, zip won't help with images. They are already compressed, so it will just add overhead. Make sure your images are not any larger than you need for display and I'd do what Mario suggested above and download them in multiple async calls (at least make the one big call asynchronous.)
A key principle of UI design is to display partial results (unless they are invalid or misleading) so that the user understands that progress is being made.
If you really need all the images to make it valid, you can download a few and display them grayed out (alpha = 0.4) or something so that it's clear that this is a partial result, but that progress is being made. The reviewer probably felt that it was taking too long to startup.
Do you change those images often? Or only once per release if at all? If they change with each release only I'd package them. If they're almost never changed, go with the one huge download (so people don't have to redownload when updating) and if they're change often, download them file by file but try to do 2-3 files at once using asynchronous download (if supported).
1) I would use something like an NSOperationQueue to download around three images at a time in the background. Much more than that and the UI starts getting choppy.
2) Also display some kind of loading indicator while this is going on.
3) What format are your images in? If you are transferring over the network you should use JPG, and consider setting the quality level to something smaller (say 6 even 5). To offset the loss of quality you could send down larger images, even with the larger number of pixels you can easily be better off with a lower quality compression.
4) If you have to use PNG to preserve transparency, consider using PNGCrush on the images before sending. As noted, zip will do pretty much nothing.
One way to speed up download of those images is to put them on a CDN. Some CDNs, like Limelight have special network optimizations for sending data to mobile devices. They also just do a better job of routing content, and have higher capacity for transmitting content. What's nice about this approach is that you might not have to change your app. However CDNs can be pricy.
Likely, your images are just way too large. You said you're worried about the 20MB app limit, but I think at that point, your images are just way too large for the phone.
Rather than zipping the files, I'm pretty sure you need to downsample the size of the images. Not only that, but you should only download the ones that you need, when you need them.
If you still want to have bulk downloads, why not have it as a side option rather than the default implementation?
In my iPhone I need to show a number of images from remote URL. Some of the URL may download some amount of data and but it may not contain actual image data. So what I need to do to check whether the downloaded data is an image data or not?
Thnx in advance,
Syam S
Do you mean that you're given the actual URLs of the images (e.g. http://sstatic.net/so/img/logo.png), and need to determine whether they're valid images, or do you mean that you're given the URL of a page which may or may not contain images?
Assuming the former (which seems more likely, and is easier than the other case), you'll want to look at the Content-type header returned by the server when you request the URL. Its value will generally be something self-explanatory, like text/html, image/png, image/gif, and so on. If you want image data, it should suffice to check whether the string starts with image/ — although you might want to refine that method if it turns out not to be accurate enough for your needs.
To get this header in an iPhone app, you'll probably want to use the methods described in Apple's Communicating with HTTP Servers guide on their iPhone developer site. If you're only interested in the headers, you might consider using CFReadStreamCreateForStreamedHTTPRequest (instead of what the guide suggests, which is CFReadStreamCreateForHTTPRequest) to read the response. This will avoid buffering all the response data, and will let you download what you need.