Resize large images in App Engine - image

I've got an app on Google App Engine that will accept image uploads from users. The problem that I envision is that users will upload these images directly from their cameras, and file sizes are often greater than 1MB, which is the limit for the image API (which would be used to resize the images).
What's the best way to accept the upload of say a 1.5MB image file, and resize it to under 1MB?

While this is not clear in the App Engine documentation, this is possible by using a combination of the Blobstore and the Image Manipulation Service.
You must:
Upload the Image into the Blobstore
Retrieve the Image from the Blobstore
Perform the Image Manipulation with an Image resulting in less than 1mb in size
I've written up a post about this -> http://socialappdev.com/uploading-and-re-sizing-large-images-on-app-engine-11-2010.

Here are two (similar) ways to solve this:
If you want to keep everything controlled yourself, you can put a resize script on a server of yours, which takes the URL to the raw uploaded image (which can be up to 10MB due to HTTP response size limit, but you would have to store it as 1MB chunks in the datastore), downloads it from your application, resizes it, and then POSTs it back to your application. All this interaction would need some kind of authorization of course, so that it can't be abused. Alternatively, POST the image directly to your external server, but then you have to either send the other form data back to your application, or use a separate form for the image upload.
Use an external imaging service. I would recommend Picnik. See their API documentation. As you can see, it lets you make a form that posts the image directly to their servers, then the user can edit the image (and resize), then the image is posted back to your server. With this solution you have to upload the image in a separate form, since Picnik receives all your POST data.
I recommend point 2, because it doesn't require you to go around Google App Engine limitations and since your users are uploading images straight from the camera, they will probably want to do something with them anyways (such as crop.)

That's a conundrum. The "obvious" answer, using google.appengine.api.images.resize, won't work because it's too big. :) So you will have to use third-party software, either on the server (which will be tricky because of App Engine's limitations) or the cilent (e.g. a Java uploader).

Related

Docpad design considerations

I'm coming from a php/mysql background. I'm most familiar with the Kohana PHP framework and I'm trying to learn Docpad. I have a loose understand at this point and I've built out my first website and blog. Static content makes a lot of sense to me on Docpad.
I'm working on my photography site where I want to be able to upload new images to a portfolio. The backend needs to handle an uploaded high-resolution image and create several different copies at different resolutions of the image. My biggest question is how do I keep track of the image meta data that I want to display? Do I generate a physical file for each image that has all the particulars I want to track and use those files as my searchable database, much like how blog posts are setup?
Or should I go the route of using something like MongoDB to store image data there where it can be queried and plugged into a layout?
Regarding handling POST or GET data, should I be reading up on the express.js docs? I'm not really sure where to turn for that.
Wordpress uses TimThumb to re-size it's images: How does WordPress.com resize images dynamically?
Then there is this re-sizing library for node: node package for file attachments and image resizing
If you wanted to created like 3 different image sizes and use the backbone collection in DocPad, then you'd add your different re-sized images to those three different collections/folders. For access the images you might just be able to do it via it's file name. So when you copy, re-size and rename the image, in the rename step, concat the image size at the end, like: coolPhoto-med.jpg and then you could just do hard links to get to the image like /spring-collection/med/coolPhoto-med.jpg or you could use query engine to access them.
The file model has a meta attribute: https://github.com/bevry/docpad/blob/master/src/lib/models/file.coffee#L17
I've yet to learn how to use it yet though.
I know we chatted yesterday on #docpad IRC but I just wanted to answer you here too. If you do code something that re-sizes images for DocPad, please do consider putting it up on Github to share with the community.

Resizing images uploaded using GWT File upload

I have a mobile app where users can upload JPGs but I want to limit the size of the image before sending it to my GAE blobstore. I don't want to have to force a user to resize the image they want to upload but rather just do it on the fly. Anyone got a way to do this without distorting the image?
There is no straight forward way to do it and no third party library in gwt yet for this.
Option 1
The best you can try is for GWT wrappers over html5 apis . You can track this on another stackoverflow question Image resizing client-side with javascript before upload to the server
Option 2
Upload and process on server side before pushing to GAE blobstore.
If I am correct blobstores maximum file size is around 2Gb. And you can send around 1Mb of data in one request of GAE blobstore service.
There is an app called AppImage that divides the file into smaller pieces. For more info on that click the below link
Large Image Resizing for Google App Engine
This is just a thought : why do you want to upload it through GAE as you can directly upload it to blobstore unless it greater the 2Gb !!!!

openreadAsync vs Bitmap for image downloading from server

I have some image urls which I want to cache locally and save so that I don't need to make a web request again and again as needed.
Now, I am confused whether there is any significant benefit of using webclient's openreadasync method over bitmap for fetching the image for first time for saving it to IsolatedStorage.
For me, I think bitmap would be a better option as I would be able to get a event for progress.
This post gives good info on various image caching options.
http://blogs.msdn.com/b/swick/archive/2011/04/07/image-tips-for-windows-phone-7.aspx
Matt mentioned the fact that default image caching only works per session. So if you are implementing your own Image caching, then you will have to implement a image downloader for which the WebClient OpenReadAsync provides a way to store file locally
If you were't considering a local cache, UriSource would have been the choice.
If you want to cache images beyond the current application instance lifetime, have a look at http://blogs.msdn.com/b/delay/archive/2010/10/04/there-s-no-substitute-for-customer-feedback-improving-windows-phone-7-application-performance-now-a-bit-easier-with-lowprofileimageloader-and-deferredloadlistbox-updates.aspx which will show a way of saving the images to IsolatedStorage and then display it from there. This means you won't have to get it over the network each time the app is run.
If you're using this for lots of images be sure to manage the images you save as well so you don't fill up the disk with lots of old images you'll never need again.

what bits of info are stored in pinterest image urls?

The first bit before the _ is the id of the pin...what are the ZZtfjmGQ used for? I'm assuming the _c is probalby something to do with size.
http://media-cache-lt0.pinterest.com/upload/33284484717557666_HZtfjmFQ_c.jpg
I'm building an image upload service in node.js and was curious what other sites do to store the image.
Final images are served from a CDN, evident by the subdomain in the URL. The first bit, as you pointed out, is the id of the image, the second bit is a UID to get around cache limitations for image versions, and the last bit is image size.
A limitation of CDNs is the inability to process the image after upload. To get around this, my service uploads the files to my Nodejs server where I then serve the image back to the client. I use a jQuery script the user can use to crop the image which sends crop coordinates back to the server and I use ImageMagick to create the various sizes of the the uploaded image. You can obviously eliminate the crop step and just use aspect ratio's to automatically create the needed image sizes. I then upload the final images to the CDN for hosting to end users.
When a user needs to update a photo already in the CDN, the user uploads to nodejs server, images are processed and sized, the UID hash is updated and then uploaded to the CDN. If you want to keep things clean (and cut on CDN cost) you can delete the old "version" at this step as well. However, in my service I give the option to backtrack to an older version if needed.
The rest of the CRUD actions are pretty self explanatory. You can read a list of images available from the CDN using the ID (My service has a user id as well as an image id to allow more robust query operations) and deleting is as simple as identifying the image you want to delete.

choosing an image locally from http url and serving that image without a server round trip

I am a complete novice to Flash (never created anything in flash). I am quite familiar with web applications (J2EE based) and have a reasonable expertise in Javascript.
Here is my requirement.
I want the user to select (via an html form) an image. Normally in the post, this image would be sent to server and may be stored there to be served later. I do not want that. I want to store this image locally and then serve it via HTTP to the user.
So, the flow is:
1. Go to the "select image url":mywebsite.com/selectImage
Browse the image and select the image
This would transfer control locally to some code running on the client (Javascript or flash), which would then store the image locally at some place on the client machine.
Go to the "show image url": mywebsite.com/showImage
This would eventually result in some client code running on the browser that retrieves the image and renders it (without any server round trips.)
I considered the following options:
Use HTML5 local storage. Since I am a complete novice to flash, I looked into this. I found that it is fairly straightforward to store and retrieve images in javascript (only strings are allowed but I am hoping storing base64 encoded strings would work at least for small images). However, how do I serve the image via http url that points to my server without a server round trip? I saw the interesting article at http://hacks.mozilla.org/category/fileapi/ but that would work only in firefox and I need to work on all latest browsers (at least the ones supporting HTML5 local storage)
Use flash SharedObjects. OK, this would have been good - the only thing is I am not sure where to start. Snippets of actionscripts to do this are scattered everywhere but I do not know how to use those scripts in an actual html page:) I do not need to create any movies or anything - just need to store an image and serve it locally. If I go this route, I would also use it to store other "strings" locally. If you suggest this, please give me the exact steps (could be pointers to other web sites) on how to do this. I would like to avoid paying for any flash development environment software ideally:)
Thank you!
You could use a data URI to display the file. Essentially you use the image data (plus a prefix) as the src attribute of an image element. If you already figured out how to read the file into memory as a base64 encoded string, using a data URI would probably be the easiest way to display the image.
OK
I was able to implement the following solution (just in case anyone has any comments or would like to know the answer)
wrote server side code that takes an image and returns its base 64 encoded version.
used the hidden iframe trick to get the base 64 encoded data into an iframe and stored it into the image by dynamically changing the image source to the data uri
For the "hidden iframe trick" - in case you are interested, there is a good article at (see www.openjs.com/articles/ajax/ajax_file_upload/response_data.php)
The only limitation is that IE does not work with images whose base 64 encoded string exceeds 32K - see http://msdn.microsoft.com/en-us/ie/dd578309.aspx. Note that only IE 8 works - IE 7 does not support data uri I believe.

Resources