views:

303

answers:

7

Hi there,

we are maintaing a database of image media in a large scale webapplication. The high resolution jpgs are big (> 15MB) and must not be made available for download in any way. Now we need to provide access to the details (crops) of the images to the clients (like a zoom-in function). The client should see a downskaled version of the image and be able to select an area of it to be viewed in the full scale mode (100%).

How could this be implemented in the most performant way (traffic and cpu wise)? We are open to any solution as long as the high resolution image file remains protected. The application is developed in c# and .net framework 3.5.

Any ideas? Thanks in advance!

A: 

I'd use S3 for storage. Create two buckets (public protected), give out url to the protected bucket's images once you have authorized the user to download them. S3 Urls can be made restful with an expiration date.

With 15Mb images you'll likely realize that you need to pre-generate the scaled/cropped version ahead of time.

I'd use a watermark of some sort on all but the original file. (like Google maps)

[Edit: Added Deep Zoom for zooming]

Check out Silverlight Deep Zoom for managing the croping and zooming (Demo). They even have a utility to generate all the cropped images.

Greg Dean
Thanks for your answer. The storage is not the problem at hand. Rather the question of when/how/how much etc crop versions to pre-generate or if there is an entirely different approach to it (e.g. a flash based solution?).
Matthias
+1  A: 

First thing you will need to do is compress and watermark the images before uploading them to the server. Then present those to the user. This will take the least CPU resources since they images will be static.

I personally would then crop the images for the full size versions and put them up along side the compressed ones. This way the client can have a view of the full image (albeit compressed and watermarked) along side a small sample of the full hi-res version.

You probably want to avoid on-the-fly image manipulation unless you have a low number of clients and a very beefy server.

semmons99
Yes, images are compressed before shown to the user. As for the crops: Problem is, we'd like to allow the client to choose the area of the highres image they'd like to see. If the image is large, it would mean a lot of pregenerated crops to be saved on the server.
Matthias
I think you either need a very fast server or a lot of web space. Allowing the user to zoom into an (nearly) arbitrary range should work when you slice your image in small enough portions (I'm thinking of sth similar to Google maps).
0xA3
(continued) I don't think that there will be too much overhead concerning disc space when you pre-generate these slices.
0xA3
What if you take Divo's idea a little further. Take an image slice it up into 9+ crops, then the user can click and get that crop returned.You would need to watermark each crop since you are presenting them with a high-res image they could (in theory) stitch them back together.
semmons99
Allowing them to select an arbitrary crop (no matter how small) could lead to abuse unless you are watermarking everything sent to the user.Like a poster said below, slicing ala google maps would be a good way to solve your dilemma.
semmons99
A: 

I would serve a low-res version of the image to the browser and hava a client side crop ui that would then send a request back to the server which will crop out the selection and send it back in high res.

PEZ
Real-time cropping of a 15Mb image on a webserver will really kill perf/scalability
Greg Dean
But how else do you meet the requirements: "The high resolution jpgs ... must not be made available for download in any way." and "The client should see a downskaled version of the image and be able to select an area of it to be viewed in the full scale mode (100%)."?
PEZ
Exactly that's the tricky question here ;)
Matthias
Way to reiterate the question PEZ.
StingyJack
Maybe you can have five (or so) pre-generated (large) crops and let the client crop from them?
PEZ
A: 

As i say to my father (that does not understand how the internet works), if you can see it on a web page, you can save it, it's just a question of how to do it.

Sergio
Being able to save a portion of it with a watermark, is fine in this scenario.
Greg Dean
A: 

There is an ajax version of Deep Zoom that you might like - See Dragon:

http://livelabs.com/seadragon-ajax/gallery/

The user is presented with a low-res version of the image; they can then zoom in on any part of it that they like.

darasd
A: 

must not be made available for download in any way.

is at odds with:

The client should see a downskaled version of the image and be able to select an area of it to be viewed in the full scale mode (100%).

... at the point you allow all areas of the image to be viewed at full res, the entire image could be stitched together. so you're effectively (if very inconveniently) making the full size image available.

none of this helps you achieve the goal though.

the way i'd do it would be to provide a 72dpi watermarked copy for use in selecting the area of the image to download. you could scale this to a % of the original if screen real estate was an issue. have the user choose top-left and bottom-right coordinates. then use something like imagemagick to copy this area out of the original to be served to the user.

if you need to conserve resources, you could have the users download from a predefined grid, so the first time grid coord 14:11 is chosen, image_1411_crop.jpg gets written to the file system, and the next time that coord is selected, the file already exists.

edit: read some of your comments on other answers...

no matter what way you go about generating and serverside caching, you're going to use the same amount of bandwidth and traffic. a 300dpi jpeg is a 300dpi jpeg no matter if it's just been generated or is sitting on the filesystem.

you have to find out whether you need to conserve CPU or disk space. if you've got a million gigs of images and only forty users, you can afford the CPU hit. if you've got forty gigs of images and a million users, go for the HDD.

nailitdown
It's not about bandwidth and traffic, its about loading a >15Mb Image into memory and trying to resize it on demand. It will be slow at best.
Greg Dean
there was a lot more to my answer than the point that the bandwidth and traffic would be unaffected no matter the solution :p
nailitdown
Rather than just down voting in spite, maybe you should provide something useful in the comments. Like the reason why. In this case, it would be "because you down voted my answer"
Greg Dean
A: 

Firstly I would pre-render watermarked versions of all the full size images saving them in a compressed file format, as well as pre-rendered low res versions.

I would serve the low res images for browsing. Then the watermarked high res image for the user to set up their cropping.

At the point of confirmation I would have a second dedicated image processing server that cropped the non-watermarked image, passed the cropped image to the webserver which sent it to the client.

That being said, it would still be possible, to create a client side script that farmed the cropped portions and stiched them together to create a full size copy of the non-watermarked image.

Martin