Delphi (since the version 3, I guess) is shipped with the standard Jpeg library implementation,
from the Independent JPEG Group(IJG). It links C-compiled code under Windows, or
can link to standard-supplied libjpeg.so from your Linux distribution.
Nowadays, most applications (Dot Net, GDI+ oriented) use Microsoft's standard
IPicture component, available as a COM object interface to any language, in any modern
Windows system. It not only handles JPEG files, but works with GIF, BMP, and other
At the beginning of this century, Intel released an optimized library for manipulating
Jpeg images, the “Intel Jpeg Library” (IJL) . This implementation, on MMX- enabled
OB systems, was two or three times faster than Microsoft or IJG implementation. So why
don’t we use it?
Here is my attempt to unify IJG and IJL approach: MyJpeg.pas links to the IJG .obj
files, and, if the IJL dll is available, will use it. The interesting point is that
it defines a “quite” standard TJpegImage class, which exposes most properties of
the Borland implementation. So you just have to rename Jpeg to MyJpeg in your uses
clause, and your software will gain from the IJL library.
Sometimes, the IJL fails to download pictures - in this case, my TJpegImage object
will transparently read it using the standard IJG, which, by definition, never fails.
Officially, “Intel no longer supports this old library and strongly recommends users
to check the Intel IPP that will bring more benefits for functionalities and performance”.
But this new library is not free to use on Windows, and guess its size? Ten of megabytes,
of course, comparing to the 190kB of our old ijl15.dll. So make up your mind, and
remember that MyJpeg can make use of IJG code if IJL fails. We won’t need Intel support
this time. :)