Here are the modifications made to the unit:
- resource leak in TJpegDecode.ToBitmap fixed (thanks Esmond
for the report)
- potential GPF issue fixed in TJpegDecode.Free
Source code is available from http://synopse.info/files/jpegdec.zip
2010-03-24. Permalink Open Source › Open Source libraries
The Fast JPEG decoder using SSE/SSE2 library file has been updated, and is now in version 1.2, released under a MPL/GPL/LGPL tri-license. It's mainly a bug issue fix.
Here are the modifications made to the unit:
- resource leak in TJpegDecode.ToBitmap fixed (thanks Esmond
for the report)
- potential GPF issue fixed in TJpegDecode.Free
Source code is available from http://synopse.info/files/jpegdec.zip
Trackback URL : https://blog.synopse.info?trackback/235
8 reactions
1 From Sapersky - 25/03/2010, 14:58
Well, looks nice, but... it really outperforms only standart jpeg unit and OleLoadPicture API func.
Intel Jpeg Library, "good old" version 1.5 (dated 2001) is 2 times faster (I suppose that IJL uses integer/MMX mode, therefore operates with less data etc).
GdiPlus (Win7) - 1.5 times faster.
2 From Sapersky - 25/03/2010, 17:18
Yes, there is a difference in quality. I can't spot it visually, but subtracting images from each other I get noize pattern - with little noize for GDI+ and more for IJL.
Seems that your code uses jpeg "smoothing". IJL also can do this, but usually I disable it for performance reasons. With smooting enabled IJL produce the same image as GDI+ and works 20% slower than your code.
I'm not sure yet that this smoothing is really needed (as I can't see the difference)... may be, I'll try more images.
About the hardware - I've tested CoreDuo and Pentium3, with the same results.
3 From A. Bouchez - 25/03/2010, 19:12
Thanks for these details.
"Smoothing' is not an used feature in most softwares... you are perfectly right!
That's why I definitively will try to wrap the last IJG library into a pure Delphi unit, with SIMD extensions.
4 From Harry - 27/03/2010, 17:56
How about "progressive JPEG". I see - it`s can not be loaded?
Sorry, if I make mistakes on my English
5 From Sapersky - 28/03/2010, 10:13
I've tried to post a link to my test, but it was not passed (antispam defence?). Trying again without "http":
sapersky.narod.ru/files/JpegLoad.zip
Screenshots of decoded image (JpegDec seems to be more noizy):
IJL: i44.tinypic.com/30u4ccp.png
JpegDec: i40.tinypic.com/2na39lu.png
6 From Sapersky - 31/03/2010, 14:02
IJL really has a lot of issues. Another one (that I forgot first) is that registry key must be set for full performance. It's not always possible, common user usually have no permission to write to HKLM.
The test is updated (same link) to set up registry.
Also some people report problems with multithreading...
But, despite of all, it is the fastest freeware library for now.
Another perspective way of fast jpeg decoding (faster than any SIMD) is using GPU (CUDA, OpenCL...), but I haven't heard about freeware GPU decoders... well... stop... googled at last moment:
sourceforge.net/projects/cudajpegdecoder/
Although I can't even run binaries (special driver version from NVidia needed).