As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I need to compress or at least drop the quality of some png images that users are uploading to my site. I already resized it but that doesn't do much for the image size.
Seeking a png/image compression or quality loss algorithm or library for .net 4.0 or under.
This is how I currently save/convert my images:
Image mainImg = ImageHelper.ResizeImage(bmp, 600, 500, false);
mainImg.Save(filePath, System.Drawing.Imaging.ImageFormat.Png);
Unfortunately, .NET (and GDI+, which the .NET graphics libraries are built on) does not support any encoding parameters for PNG. In fact, if you call GetEncoderParameterList on your image with the PNG encoder Clsid, you'll get a "Not implemented" exception.
Even more unfortunate is that both ImageFormat and ImageCodecInfo are sealed classes and you can't just add new codecs to what .NET can natively access. Microsoft dropped the ball on this one.
This means your alternatives are, in decreasing order of masochism:
1) Implement a save function on your own in .NET that implements RFC 2083,
2) Implement a save function based off porting libpng to .NET,
3) Call unmanaged code that was built from libpng directly
libpng has great documentation and is free, both in availability and license permissiveness.
PNG is generally a lossless compression scheme, which means image quality is never reduced unless you reduce the pixel count (size) or color depth. There are three ways to reduce the file size of PNG images:
Reduce the pixel count (by downscaling the image); there's an obvious loss of resolution here
Using a different precompression filters/DEFLATE compressor parameters (OptiPNG is my favorite tool to automatically choose the best combination of filters/compressor settings)
Reducing the color depth from true color to 256 (or less) colors will give you substantial byte savings, but usually at great visual cost (especially for photographic images)
It seems like .NET doesn't have a built-in way to change precompression filters or compressor parameters of PNGs, so you'll have to use an external library. OptiPNG or any of the other PNG optimization tools aren't native .NET libraries, so you'll have to deal with P/Invoking the libraries or running a separate process to.. process each image. However, you're often looking at a savings around 5% or less (although I've seen as much as 40%) since this is ultimately a lossless process.
I'd recommend against reducing color depth in the automated scenario you describe, because the results can look truly awful (think dithered GIFs of old). (However, If you're doing manual optimization, look at Color Quantizer on Windows and ImageAlpha on Mac.)
Realistically, the best way you can reduce file size at the expense of quality is to just convert to JPEG, which requires no external dependencies, and is designed to be a lossy compression algorithm:
mainImg.Save(filePath, System.Drawing.Imaging.ImageFormat.Jpeg); // make sure you change `filePath` to end with jpg instead of png.
Unfortunately, .Net's image processor for png won't do any optimization heuristics on the output. Your best bet is to have an optipng/pngcrush binary available on the server, render the resized output to a temporary file, then use pngcrush on it via a System.Diagnostics.Process.
For the most part, if the uploads are photographs and the original format is JPEG, then you will be better served by using JPEG output.
Related
imageresing.net community and developers.
Please, clarify me some details about imageresing.net internals.
Does imageresing.net use .NET Drawing library to recompress jpegs? If not - does it use a 3rd party engine or some internal algorithms?
Are there performance benchmarks? I'd like to compare imageresing.net with other libraries: libjpeg, Intel Integrated Performance Primitives, etc.
Thanks in advance,
Anton
ImageResizer offers 3 imaging pipelines.
GDI+ (System.Drawing) The default. 2-pass high-quality bicubic with pre-smoothing. Very fast for the quality provided. (Avg. 200-300ms for resizing.) A recent windows update makes GDI+ parallelize poorly, but this is being actively investigated by MSFT.
WIC (What WPF also uses). 4-8x faster (20-200ms for resizing). Single-pass resizing causes lots of moire artifacts and causes blurriness (in both Fant and Bicubic modes). No really high quality resizing is available within Windows Imaging Components.
FreeImage. If you need to support DSLR formats or access Lanczos resampling (top-tier quality), FreeImage is your library. It's slower than the others (often 800-2400ms), large, monolithic, and hard to audit, so we only recommend using it with trusted image data. We use a custom version of FreeImage built against libjpeg-turbo, which is significantly faster than libjpeg.
You can mix and match encoders, decoders, and (to some extent) resizing algorithms. Some algorithms are implemented internally for quality reasons, while most are implemented in C/C++ in dependencies.
End-to-end comparison benchmarking is kind of absurd if you care about photo quality, since you can never compare apples to apples. Back in 2011, I did some benchmarks between GDI+ and WIC, but photographers and graphics designers tend to find WIC image quality unacceptable, so it's not particularly fair.
We regularly benchmark each pipeline against itself to detect performance improvements or regressions, but comparing pipelines can be deceptive for a numer of reasons:
Do you care about metadata? libjpeg-turbo is (wierdly) 2-3x faster at reading jpegs when you disable metadata parsing. If you want to auto-rotate based on camera exif data, you'll need that info.
Do you care about color correctness? Jpeg isn't an RGB format. If it has an ICC profile, the right thing to do is convert to sRGB before you resize. That's slow.
Do you care about resizing quality? There are a hundred ways to implement a bicubic resizing filter. Some fast, some slow, most ugly, some accurate. Bicubic WIC != Bicubic GDI+. You can get < 20ms end-to-end out of ImageResizer WIC in nearest neighbor mode - if you're cool with the visual results.
Do you care about output file size? If you're willing to spend more clock cycles, you can gain 30-80% reductions in PNG/GIF file sizes, and 5-15% in jpeg. If you want to add 150-600ms per request, ImageResizer can create WebP images that halve your bandwidth costs (WebP is more costly to encode than jpeg).
You can make sense of micro-benchmarks (is libjpeg-turbo 40% faster than libjpeg under the same circumstances, etc). You can even compare certain simple low-quality image resizing filters (nearest-neighbor, box, bilinear) after excluding encoding, decoding, and color transformation.
The problem is that truly high-quality resizing is really complex, and never implemented the same way twice. There are a vanishingly small number of high-quality implementations, and an even tinier number that have sub-second performance. I ordered a dozen textbooks on image processing to see if I could find a reference implementation, but the topic is... expertly avoided by most, and only briefly touched on by others. Edge-pixel handling, pre-filtering, and performance optimization are never mentioned.
I've funded a lot of research into fast high-quality image resizing, but we haven't been able to match GDI+ yet. ImageResizer's default configuration tends to beat Photoshop quality on many types of images.
A fourth pipeline may be added to ImageResizer in the near future, based on our fork of libgd with custom resizing algorithms. No promises yet, but we may have something nearly as high quality as GDI+ with similar single-threaded (but better concurrent) performance.
All our source code is on GitHub, so if you find something fast that you'd like to demo as a plugin or alternate pipeline, we'd love to hear about it.
Our web server needs to process many compositions of large images together before sending the results to web clients. This process is performance critical because the server can receive several thousands of requests per hour.
Right now our solution loads PNG files (around 1MB each) from the HD and sends them to the video card so the composition is done on the GPU. We first tried loading our images using the PNG decoder exposed by the XNA API. We saw the performance was not too good.
To understand if the problem was loading from the HD or the decoding of the PNG, we modified that by loading the file in a memory stream, and then sending that memory stream to the .NET PNG decoder. The difference of performance using XNA or using System.Windows.Media.Imaging.PngBitmapDecoder class is not significant. We roughly get the same levels of performance.
Our benchmarks show the following performance results:
Load images from disk: 37.76ms 1%
Decode PNGs: 2816.97ms 77%
Load images on Video Hardware: 196.67ms 5%
Composition: 87.80ms 2%
Get composition result from Video Hardware: 166.21ms 5%
Encode to PNG: 318.13ms 9%
Store to disk: 3.96ms 0%
Clean up: 53.00ms 1%
Total: 3680.50ms 100%
From these results we see that the slowest parts are when decoding the PNG.
So we are wondering if there wouldn't be a PNG decoder we could use that would allow us to reduce the PNG decoding time. We also considered keeping the images uncompressed on the hard disk, but then each image would be 10MB in size instead of 1MB and since there are several tens of thousands of these images stored on the hard disk, it is not possible to store them all without compression.
EDIT: More useful information:
The benchmark simulates loading 20 PNG images and compositing them together. This will roughly correspond to the kind of requests we will get in the production environment.
Each image used in the composition is 1600x1600 in size.
The solution will involve as many as 10 load balanced servers like the one we are discussing here. So extra software development effort could be worth the savings on the hardware costs.
Caching the decoded source images is something we are considering, but each composition will most likely be done with completely different source images, so cache misses will be high and performance gain, low.
The benchmarks were done with a crappy video card, so we can expect the PNG decoding to be even more of a performance bottleneck using a decent video card.
There is another option. And that is, you write your own GPU-based PNG decoder. You could use OpenCL to perform this operation fairly efficiently (and perform your composition using OpenGL which can share resources with OpenCL). It is also possible to interleave transfer and decoding for maximum throughput. If this is a route you can/want to pursue I can provide more information.
Here are some resources related to GPU-based DEFLATE (and INFLATE).
Accelerating Lossless compression with GPUs
gpu-block-compression using CUDA on Google code.
Floating point data-compression at 75 Gb/s on a GPU - note that this doesn't use INFLATE/DEFLATE but a novel parallel compression/decompression scheme that is more GPU-friendly.
Hope this helps!
Have you tried the following 2 things.
1)
Multi thread it, there is several ways of doing this but one would be a "all in" method. Basicly fully spawn X amount of threads, for the full proccess.
2)
Perhaps consider having XX thread do all the CPU work, and then feed it to the GPU thread.
Your question is very well formulated for being a new user, but some information about the senario might be usefull?
Are we talking about a batch job or service pictures in real time?
Do the 10k pictures change?
Hardware resources
You should also take into account what hardware resources you have at your dispoal.
Normaly the 2 cheapest things are CPU power and diskspace, so if you only have 10k pictures that rarly change, then converting them all into a format that quicker to handle might be the way to go.
Multi thread trivia
Another thing to consider when doing multithreading, is that its normaly smart to make the threads in BellowNormal priority.So you dont make the entire system "lag". You have to experiment a bit with the amount of threads to use, if your luck you can get close to 100% gain in speed pr CORE but this depends alot on the hardware and the code your running.
I normaly use Environment.ProcessorCount to get the current CPU count and work from there :)
I've written a pure C# PNG coder/decoder ( PngCs ) , you might want to give it a look.
But I higly doubt it will have better speed permance [*], it's not highly optimized, it rather tries to minimize the memory usage for dealing with huge images (it encodes/decodes sequentially, line by line). But perhaps it serves you as boilerplate to plug in some better compression/decompression implementantion. As I see it, the speed bottleneck is zlib (inflater/deflater), which (contrarily to Java) is not implemented natively in C# -I used a SharpZipLib library, with pure C# managed code; this cannnot be very efficient.
I'm a little surprised, however, that in your tests decoding was so much slower than encoding. That seems strange to me, because, in most compression algorithms (perhaps in all; and surely in zlib) encoding is much more computer intensive than decoding.
Are you sure about that?
(For example, this speedtest which read and writes 5000x5000 RGB8 images (not very compressible, about 20MB on disk) gives me about 4.5 secs for writing and 1.5 secs for reading). Perhaps there are other factor apart from pure PNG decoding?
[*] Update: new versions (since 1.1.14) that have several optimizations; if you can use .Net 4.5, specially, it should provide better decoding speed.
You have mutliple options
Improve the performance of the decoding process
You could implement another faster png decoder
(libpng is a standard library which might be faster)
You could switch to another picture format that uses simpler/faster decodeable compression
Parallelize
Use the .NET parallel processing capabilities for decoding concurrently. Decoding is likely singlethreaded so this could help if you run on multicore machines
Store the files uncompressed but on a device that compresses
For instance a compressed folder or even a sandforce ssd.
This will still compress but differently and burden other software with the decompression. I am not sure this will really help and would only try this as a last resort.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Say I am making a 2D Tile Based game in C# using System.Drawing for graphics.
OOP Layer for GDI?
The System.Drawing namespace provides access to GDI+ basic graphics functionality. ~ MSDN
Back when I was starting out Graphics & Game programming in C, a lot of books such as this one taught me that a software-rendered API like GDI was not efficient enough for Double-Buffered 2D games running at a decent FPS. So does Microsoft .NET's System.Drawing implementation fall into the same category? Does it use GDI & GDI+ under the hood, or can it use a different, faster backend?
How Much FPS Can I Hope For?
Even if System.Drawing can only use GDI, is it impossible to make a game run at a decent Frame rate, say 50-60 frames per second, with GDI?
It's not really a question of it being fast enough as it is it being suitable for the task you want to perform. In all honesty, it's quite easy to implement basic functionality to do the drawing you require using for instance XNA, and you get so much for free. There is simply no reason to go into System.Drawing for making games.
The book you linked in quite ancient, while it contains a few algorithms that never goes out of style most of it is really outdated.
As to how much FPS you can get from System.Drawing, you can probably get enough FPS from it from a simple tile based game. It's going to work if you do it that way, but it will hinder you from making real progress later on - especially as the threshold for making games using XNA is so low these days.
It is quite unguessable what kind of FPS you'll get, it entirely depends on how intricate your scenes are. The biggest restriction in GDI/+ rendering is that bitmaps are stored in main memory, not video adapter memory. So most anything you draw has to be copied from RAM to the video adapter's frame buffer. Sure, that's relatively slow but unavoidable as long as you don't adopt an API that can manage memory on the video adapter. There are few reasons left to avoid this kind of API, there isn't any hardware left that doesn't support DirectX.
The equivalent of page flipping is easy to get, just set the form's or control's DoubleBuffered property to true. Anything you draw goes into a back-buffer first, that buffer is blitted to the video adapter after the Paint event completes. The only thing you won't get is synchronization with the adapter's vertical refresh interval so tearing is pretty unavoidable. How noticeable that will be depends a great deal on how quickly you move objects in the scene.
The only other detail is the pixel format of any bitmaps you draw. Sprites, textures, that sort of thing. The format you pick is very important. On current hardware, Format32bppPArgb is ten times faster than any of the other ones. If you do any rescaling on the bitmaps then the Graphics.InterpolationMode property is important for speed. The good ones are expensive. You can rescale them in a worker thread as long as you make sure that only one thread ever accesses the bitmap at the same time.
But be sure to have a look at DirectX (SlimDX for example) and XNA. Hard to beat for convenience, just a lot less work to do.
I want to compress bitmaps to PNG with different compression levels as these levels are available in JPEG compression in C#. I have 20 to 30 images of different sizes to process in 1 sec. Is there any library to achieve this compression in PNG with different compression levels?
A lossless compression method does not have to be single quality level. I mean, some lossless compression methods have some parameters to choose speed/compression ratio trade-off. It's up to author.
As to PNG compression, it's actually bunch of filters and deflate algorithm. Considering deflate has a redundant encoding stage (e.g. two different compressors can produce completely different output, yet still they can be decompressed by any valid decompressor), it's no wonder several programs outputs different PNGs. Note that, I'm still not taking filters into account. There are several filters and there is no "best" filter i.e. it's quality varies by image.
Due to it's redundant feature, some people wrote PNG optimizers which take a regular PNG as input to produce smaller PNG without any perceptual loss. Some of them applies some tricks such as filling completely transparent area with some predictable colors to increase compression. But, in general they tweak parameters in a brute-force fashion.
Now, simplest answer for your question could be that you have two options:
If you're going to run your executable on a desktop environment, you can use one of these tools as an optimizer. But, in shared hosting you can't use them due to possible privileges.
You can write your own PNG writer in .NET that takes into account some brute-force parameter tuning.
According to this answer C#: Seeking PNG Compression algorithm/library PNG in C# is a lossless compression library, e.g. does not support multiple quality levels.
The wiki page on PNG (http://en.wikipedia.org/wiki/Portable_Network_Graphics) seems to confirm the compression format is lossless (e.g. has only a single compression level)
Some googling suggests there is research on lossy versions of PNG
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
What is the best way that uses less CPU has better performance for player a sequence of images in C#?
I'm writing an application for an industrial touch panel wince 5. The images are a maximum of 100kb each. Unfortunately I have to use C# because this is a form that must be integrated into an existing application.
Integrating into a C# application does not mean you have to use C# - you can write code in C++ or other languages and use p/invoke to call it from C#. But unless you're doing something really inefficient in C# you can get pretty decent performance out of it (I work on what is essentially a flight simulator written in C#, and it's pretty high performance - not as high as we could achieve with C++, but still a perfectly viable/realistic alternative, and it's so much faster to develop).
However, unless you are writing a realtime app for a very low-spec CPU and it's already struggling to keep up with its tasks, loading and displaying a 100kB image at any likely framerate shouldn't be much of a problem.
As you don't really specify the bounds of what you can do, it's hard to give a precise answer.
In general, it would make sense to use DirectX/OpenGL in preference to GDI in preference to GDI+ to get decent rendering/blitting performance.
If you have control over it, then there are many file formats that you can use which will help the speed (by compressing the data well to minimise the amount of data to be loaded, and/or by using hardware decompression approaches, better data streaming and caching approaches, pre-processing to optimise the image data to suit the target hardware, etc). If you have this much flexibility you may be able to use a video playback library or even an external video playback application that will do all the work for you, leaving you to write a trivial bit of "control logic" in C#. This will get you a much more efficient system than you are likely to achieve by rolling your own solution.