All times in my life, I save images on my server as files:
the originals
the thumbnails
the original with watermarks
... all as files in folders.
But today, I'm viewing google images, and the src of images is a base64 encoded hash. What benefit does Google get from serving images in this manner? Why would someone do that instead of just serving images conventionally?
google is sort of obsessed with latency; latency for the page load goes up if your browser has to go and make a separate request to the web server for every image on the page. you can eliminate this latency by writing the data of the image right into the page when you generate the page. i actually see a lot of image-heavy sites, especially blogs, using this technique nowadays.
just because the image is included in the page doesn't necessarily mean it's not stored as files on the web server -- just that the web server process that generated the page has already opened and read the image file and then wrote it's data into the page. google is probably storing the images in it's proprietary and secret data store, but you don't have to.
Related
I'm in the process of building my website and have come across something I want your opinions on.
I've noticed that even though I've compressed my photos A LOT (18mb to 500kb or so) they take a while to load when I display them through my site. That being said, if I pull random photos from the web and use the link to display them, they load almost instantly.
With that being the case, would uploading all my photos to Flickr, then pulling the image URL and using that as my img src be better than using the actual file from my server as my img src?
Pros and Cons?
Obviously if Flickr ever went down I'd be hurting, but if it means that the other 99.99% of the time my photos load faster I'd be all for it.
Thoughts?
Usually those images are hosted on a CDN, which means they are on multiple servers throughout the world, while images on your site are only on one. That's why theirs load faster.
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.
On my new site, I display around 50-60 thumbnails per page using my one of the plugin.
About plugin:
For every requested post id, it
extracts content for the post from
DB and find out the image url.
It generates thumbnail for found
image URL.
I wanted to minimize number of hits to the server in generating the thumbnail. If server is cache enabled then it can reduce many of the hits. But i was willing to separate the 2nd part from the plugin and to host it on any other server/CDN where i/other can request to generate thumbnail without any charges.
I tried free webhosting provider. but i felt they are generally slow/down maximum of time.
Please suggest the approach or CDN, if any...
Or any online image api which can resize/zoom/crop/edit an image, if i pass the image url.
It will be very hard (almost impossible) to find a reliable server/CDN that will generate thumbnails of images for free.
TANSTAAFL
Assuming your plugin uses several standard wordpress function, you might be able to use another plugin which takes the generated thumbnails and uploads them to another server. I recommend W3 Total Cache.
You could also try CoralCDN to take some load off your server.
So: You can use CoralCDN (or similar) and just point the URLs of your thumbnails through it, or you can have a caching plugin like W3TC upload the files to an almost-free site like Amazon S3.
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.
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).