I am building a online store for hand made jewelry. Of course there is a lot of high quality pictures that i need to show, first in small sizes and when a client clicks on the image, than redirect him to a page with a same image in high quality.
What is a better way:
on saving image save two images one in low quality and the second in original quality
or
onload image use Bitmap to lower the quality?
It depends.
Resizing on demand causes a heavier server load. When a lot of people are accessing the site this might be an issue.
Resizing on upload reduces this problem.
Resizing on your client using image processing software does usually produce the best quality with low file size.
The "normal" resize-functions in .NET is far away from that quality.
Also: Consider caching. The IIS offers everything to use this, perhaps in combination with an eTag.
I would resize them on upload/addition. I would also make sure to name them appropriately to their size, like gold_ring_640_480.jpg.
Then, should I need to change the size of the preview, I would add functionality to resize it lazily on demand if a required picture size does not exist.
Image_240p exists?
not: create
save _240p
use the image
You don't need to save all image size . For my all website, I get image on the fly depend on dimension that I need. When have a request with file size, I will create a resized image on disk. In the next time, with the same request, I just check:
if file already in browse cached, I will return the header mention that website just get image from cache.
if file not in browse cache, I will check that "the file already generate in disk". If the file is available, just return the file to response
if file not in browse cache and not in disk. I will generate it and return the file content.
For image caching you can see this reference :https://developers.google.com/speed/docs/best-practices/caching
For image resize on the fly by .net: you can refer to : http://www.codeproject.com/Articles/191424/Resizing-an-Image-On-The-Fly-using-NET
Related
I found out that there are two ways to read the image info using default c# library. One of them is
System.Drawing.Image image = new Bitmap("file..path");
Another one is :
Image image = Image.FromFile("file..path");
May anyone tell me which one will run faster if I need to read a lot of images(nearly 100TB data).
I found out that there are two ways to read the image info
You know, if it is just the image info you are after then I wouldn't use either function as both load the entire image into memory from disk - a rather wasteful exercise of the computer's resources.
Instead you should just load the image file header whether it be EXIF; BITMAPINFOHEADER or other depending on the image format. There are ways to load such info via .NET (see links below).
Image headers
Apart from RAW image file formats (not necessarily that which is output from SLR cameras), most image file formats have a header that can be loaded prior to loading the image raster data into memory from disk. In fact it is a generally a requirement that the header is read first because otherwise you would not know how much memory to allocate prior to loading the image.
How wide is it?
How tall?
How many bits per pixel (colour depth)?
...and so forth. These are all answered by reading the image file header first. As the name suggests, information about the image is generally near the start of the file. Exact formats and layout depends on the file format in question. See BMP; PNG resources for more info.
Here's some suggestions on loading image headers
Obtain image width and height without loading image in .NET?
Getting image dimensions without reading the entire file
Bitmap Storage
We've implemented the base server for ImageResizer, but we have one more requirement. We are dealing with user uploaded images. Sometimes users want to upload 5MB, 10MB, even 30MB images (some are from surveillance footage and this is expected). But we don't want to store the full image size when over a certain threshold. I'm no imaging expert - maybe we should use the client ImageResizer API and set the dpi, or maxwidth/maxheight? What is the best practice for scaling down image size?
Look at FileContentLength and do a ?maxwidth=1000&maxheight=1000 if over some specified size?
Look at the width/height of the image and scale down accordingly? Currently ImageResizer has no way to "Get" image dimensions.
I have seen this post, but we don't want to do this on our thumbnail (150x150) images obviously.
Do you care about file size or type/resolution? If the former, just do
if (post.FileContentLength > MAX_SIZE){
//Use ImageResizer
}else{
//store as-is
}
Otherwise, always use ImageResizer and specify &maxwidth=3200&maxheight=3200.
If you're worried about storage or bandwidth, then file size might be sufficient.
The downside to leaving files as-is: Metadata will be retained, and corrupted or non-web-friendly image formats will stay web-unfriendly. Very high resolution images can sometimes compress to very tiny file sizes; there's no linear correlation, so if your consumers (like mobile devices) crash on high-megapixel images, then you could have a problem.
The upsize to leaving files as-is: Users may have already optimized their images, so you won't make it 'worse'. Metadata will be retained (if that's a good thing).
Usually we suggest only modifying uploading images prior to storage for file size reasons, and then re-compressing all images using the ImageResizer URL API and Slimmage.js to ensure clients get an appropriate image for their device.
Say for example that you have a 30,000 x 30,000 image, but at any given time you would only need a specific section of it that is for example 512 x 512.
Is there a way (or framework) to iterate or query for the pixels you are looking for without having to load the entire image into memory first?
Check out Microsoft's DeepZoom. A good primer is here.
DeepZoom accomplishes its goal by partitioning an image (or a
composition of images) into tiles. While tiling the image, the
composer also creates a pyramid of lower resolution tiles for the
original composition.
You can download the DeepZoom composer here.
Also check out OpenSeadragon for a JavaScript solution.
It depends.
If your image is a jpeg/png, when you load a part, all must be loaded (because of compression)
If the image is a bmp, you can create your own load, because is a disk bitmap.
My advice is to create separate images of 512x512 and load separately (it's what google maps do!)
Goal:
I have lots of pictures in many sizes (both dimensions and file size)
I'd like to convert these files twice:
thumbnail-size pictures
pictures that will look OK on a web page and will be as close to a full screen as possible... and keeping the file size under 500KB.
HTML Questions:
A. What is the best file format to use (jpg, png or other) ?
B. What is the best configuration for web ... as small as possible file size with reasonable quality?
C# Questions
A Is there a good way to achieve this conversion using C# code (if yes, how)?
Try the code in this small C# app for resizing and compressing the graphics. I have reused this code for use in an ASP.NET site without too much work, hopefully you can make use of it. You can run the app to check quality fits your needs etc.
http://blog.bombdefused.com/2010/08/bulk-image-optimizer-in-c-full-source.html
You can pass the image twice, specifying dimensions for a thumbnail, and then again for your display image. It can handle multiple formats (jpg, png, bmp, tiff, gif), and reduce file size significantly without loosing noticeable quality.
On .jpg vs .png, generally jpg is better as you will get a smaller file size than with png. I've generally used this code passing a quality of 90%, which reduces file size significantly, but still looks perfect.
I think PNG is better format for WEB than JPEG that always uses lossy JPG compression, but its degree is selectable, for higher quality and larger files, or lower quality and smaller files. PNG uses ZIP compression which is lossless, and slightly more effective than LZW (slightly smaller files).
In C# you can use System.Drawing namespace types to load, resize and convert mages. This namespace wraps GDI+ API.
A. For graphics I would use png and for fotos jpg.
B. Configuration?
C. There are tons of post that explain that:
http://www.codeproject.com/KB/GDI-plus/imgresizoutperfgdiplus.aspx
Resizing an Image without losing any quality
Got a question. I have images hosted on my server. I already know of the method when an image is uploaded to resize it and save, but I have another thought in mind.
I was wondering if there is a way to resize when the image is requested from the user. Not when it was uploaded by the user.
So for example a user goes to upload an image and I DO NOT RESIZE it and save another copy of the resized image. Instead, when the image is requested by the user via an ASP.NET img control/tag it would resize the image on the fly to display it and display it via the img tag/control.
Why would I want to do this?
To save on disk space. Most servers have a disk space limit, but not a server processing limit. So I would like to save on disk space and use the processing space instead.
EDIT: As a startup website its currently better that I save disk than saving processing time. I don't have much money for large amount of space at this moment. Hopefully it will change when the site launches.
Any ideas? Thanks guys and girls.
I assume you can 'control' the urls to the resized images, so for example the full-sized image might be referenced as <img src="uploads/myphoto.jpg"/> the thumbnail could be to an ASPX or ASHX like <img src="uploads/myphoto.jpg.ashx"/>?
This article on CodeProject - Dynamic Image Resize seems to have exactly the source code you are looking for (and although it's in VB, it shouldn't be hard to port if you're a C# person). Hope that helps.
Finally, I'd encourage you consider the various forms of caching (both using Http-Headers, to ensure the images are cached at the client or proxy whenever possible; and using built-in ASP.NET features to avoid unnecessary processing of the same images over-and-over).
Although you'll be saving disk-quota, you're effectively slowing down every other page/request... just a thought.
Dynamic image resizing has numerous advantages, the least of which is reduced disk space usage. However, it does need to be combined with a form of persistent caching, such as either Amazon CloudFront or a disk cache.
Dynamic image resizing gives you great agility on your web site, whereas pre-generating image variants locks you in, preventing the eventual changes you will have to make. When combined with caching, there is no run-time performance difference between the two.
The ImageResizer library offers disk caching, CloudFront caching, and correct memory and cache management. It's been constantly improved and maintained since 2007, and is quite bulletproof. It's running a few social networking sites as well, some having over a million images.
It's a time-tested, traffic-tested, and unit-tested library :) It's also extremely simple to use - you just add ?width=x&height=y to the query string. Functionality can be added via 20+ plugins, so you won't be weighed down by unused code and features.
The article mentioned by CraigD is inherently limited in its performance by the fact that it uses an HttpHandler instead of using an HttpModule - an HttpHandler cannot pass a request back to IIS native code for execution after the resized image is written to disk. It also doesn't adjust jpeg encoding properly or play well with the ASP.NET cache or URL authorization system. Although, I do have to admit - compared to most of the sample code I've seen, it violates far fewer of the image resizing pitfalls I've compiled.
I strongly suggest using the ImageResizer library. It's good code, I wrote it :) If you do end up using sample code or writing your own, please avoid these pitfalls!
You can create an implementation of IHttpHandler to respond to image requests, in that handler you can have code that loads the image from disk and transforms to it a size that is needed. You need to return the proper mime type with the response, and use the WriteBytes method (or something like it, I forgot the name). Also, you may look into content expiration headers, so that the image may not have to be loaded every time by the same client, but is instead cached.
You claim unlimited processing but limited disk space. Most of the time, even if they don't enforce a processing limit, as you have more customers, hits to your site, processing will be a worse bottleneck than storage space, and it will cost more to add more processing. Furthermore,
If you have large images, resized and compressed versions will occupy %10 of the space of the originals, even if you store a display and thumbnail version.
Else, just serve them and display them resized by browser, it will be faster.
It is not really actual resize of image, it is rather resize when you display an image, but i used with success just simple
<img src="myimage" height="height you want to give" width="width you want
to give" alt="" />
It is working every time.