views:

166

answers:

3

And hopefully with as little loss as possible, as I've heard the implementation put forward by a guy named Guido Vollbeding. Standard GDI+ doesn't seem to have this capability, and all I've found so far are either specs or fully-integrated tools. A lean, pluggable .NET component would be highly desirable. What are common pitfalls if it comes to that I have implement it myself?

Every ideas and guidances are appreciated!

EDIT: My aim is to bypass the obvious cycle of decompressing into .NET Bitmap, resizing it there then compressing it again. This article seems to point to the right way, but so far I've never seen any .NET implementation

A: 

I have used code from CodeProject successfully for this previously.

Jason
Thanks, I've look into that article. But what the author described has been the standard approach, which didn't take advantage of the JPEG block structure, and also required an extra decompression/compression cycle.
Heartless Angel
+2  A: 

This is pretty easy using the .NET Bitmap class:

void ResizeImage(string inFname, string outFname, float scale)
{
    Bitmap bmpOrig = new Bitmap(inFname);
    int w = (int)(scale * bmpOrig.Width);
    int h = (int)(scale * bmpOrig.Height);
    Bitmap bmpNew = new Bitmap(bmpOrig, new Size(w, h));
    bmpNew.Save(outFname, ImageFormat.Jpeg);
}

You'll need to add a reference to System.Drawing, and use both System.Drawing and System.Drawing.Imaging in your code:

I can't say how much loss that will have.

Jim Mischel
I've been using that for generic simple resize. My question is to speed it up in special cases where a better algorithm can take advantage of the 1/2, 1/4, 1/8 downscale ratios.
Heartless Angel
A: 

I don't know of any algorithms that specifically handle 1/(2^n), but if you can find one you will need to be able to lock the bits on the bitmap (if you want any reasonable form of speed). Using set/get pixel is a poor idea.

Clickety

Jonathan C Dickinson