Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2016-03

Using libjpeg

14 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael Van Canneyt
to Aradeonas
Aradeonas wrote 6 lines
Hi, I want use libjpeg and I found?pasjpeg package in fpc that contains jpeglib.pas unit but I coudnt find a working demo to know how load a jpeg file and show it. Can anyone point me to a better direction?

pasjpeg is very low-level. Why not use tfpimage ?
use the fpimage unit, see the example converter program.

Michael.

Reply by email

Mattias Gaertner
to Michael Van Canneyt
Show quoted text 8 lines
On Wed, 30 Mar 2016, Aradeonas wrote: > Hi, > > I want use libjpeg and I found?pasjpeg package in fpc that contains > jpeglib.pas unit

Unit jpeglib does not use libjpeg.

Show quoted text 6 lines
> but I coudnt find a working demo to know how load a > jpeg file and show it. > Can anyone point me to a better direction? pasjpeg is very low-level. Why not use tfpimage ? use the fpimage unit, see the example converter program.

fpreadjpeg, which is using fpimage, is an example for loading a jpeg using jpeglib.
And this in turn is used by the LCL.
So, a short LCL example loading and showing a jpeg using jpeglib is:

Put a TImage onto the form and add to FormCreate:

  Image1.Picture.LoadFromFile('example.jpg');

Mattias

Reply by email

Aradeonas
to Mattias Gaertner

Thanks but I need libjpeg using because of speed and fpimage with UsePalette := False is not fast enough.
My tests with libjpeg.dll and this header[1] id much faster than fpimage (half the time) so I wanted to have a native way using pasjpeg instead of a dll.

Regards,
Ara

Links:

1. http://www.dev-center.de/header/libjpeg?cat=header&file=libjpeg

http://www.fastmail.com - Same, same, but different... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160331/cb106c29/attachment.html>

Reply by email

Sandro Cumerlato
to Aradeonas

Hello Ara, my tests with libjpeg-*turbo* are even more promising.

The following comparison between LCL and libjpeg-*turbo* was made decompressing for about one minute a sequence of several 4000x3000 JPEG pictures. The results are expressed in "pictures per second" and prove that libjpeg-*turbo* is about 7-8 times faster than LCL: AMD E2-1800 1.70 GHz
*Turbo i386-win32*
LCLlibjpeg-turboRatio
0.32 2.46 7.69x
*Turbo x86_64-win64*
LCLlibjpeg-turboRatio
0.36 2.72 7.56xIntel Pentium N3520 2.16 GHz
*Turbo i386-win32*
LCLlibjpeg-turboRatio
0.41 3.06 7.46x
*Turbo x86_64-win64*
LCLlibjpeg-turboRatio
0.43 3.35 7.79xIntel Core i5-4300 2.50 GHz
*Turbo i386-win32*
LCLlibjpeg-turboRatio
1.01 8.41 8.33x
*Turbo x86_64-win64*
LCLlibjpeg-turboRatio
1.10 9.18 8.35x

Best regards,
Sandro Cumerlato

Aradeonas wrote 22 lines
Thanks but I need libjpeg using because of speed and fpimage with UsePalette := False is not fast enough. My tests with libjpeg.dll and this header <http://www.dev-center.de/header/libjpeg?cat=header&file=libjpeg> id much faster than fpimage (half the time) so I wanted to have a native way using pasjpeg instead of a dll. Regards, Ara -- http://www.fastmail.com - Same, same, but different... -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160417/7e0aa039/attachment.html>

Reply by email

Aradeonas
to Sandro Cumerlato

Very interesting! Thanks for sharing, maybe I was wrong in implementation. Do you used any different header or implementation? Can you share it?

@All : Is there a way to use?libjpeg-*turbo *with Lazarus *without* using an external library like DLL?
Regards,
Ara

http://www.fastmail.com - Faster than the air-speed velocity of an unladen european swallow -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160417/c82bf375/attachment.html>

Reply by email

Marc Weustink
to Sandro Cumerlato: Hello Ara, my tests with libjpeg-*turbo* are even more promising. The following…
Sandro Cumerlato wrote 6 lines
Hello Ara, my tests with libjpeg-/turbo/are even more promising. The following comparison between LCL and libjpeg-/turbo/ was made decompressing for about one minute a sequence of several 4000x3000 JPEG pictures. The results are expressed in "pictures per second" and prove that libjpeg-/turbo/ is about 7-8 times faster than LCL:

How did you compare ?

IE, whats the source ?

Marc

Reply by email

Sandro Cumerlato
to Aradeonas: Very interesting! Thanks for sharing, maybe I was wrong in implementation. Do you used…

Hello Ara,
I've used the attached header conversion for turbojpeg 1.4.2.

It is incomplete, but quite usable.

Best regards,
Sandro Cumerlato

Aradeonas wrote 22 lines
Very interesting! Thanks for sharing, maybe I was wrong in implementation. Do you used any different header or implementation? Can you share it? @All : Is there a way to use libjpeg-*turbo *with Lazarus *without* using an external library like DLL? Regards, Ara -- http://www.fastmail.com - Faster than the air-speed velocity of an unladen european swallow -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160418/b9f0dd71/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: turbojpeg.zip
Type: application/zip
Size: 12485 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160418/b9f0dd71/attachment-0001.zip>

Reply by email

Sandro Cumerlato
to Marc Weustink: How did you compare ? IE, whats the source ? Marc

Hello Marc,
images are preloaded into separated memory streams, the core part of the comparison is performed by a separated thread:

procedure TMyThread.Execute;
var
  jpegDecompressor: tjhandle;
  jpegWidth: cint;
  jpegHeight: cint;
  jpegSubsamp: cint;
begin
  while (not Terminated) do
  begin
    case FTest of
      1 : begin // LCL
        FPicture := TPicture.Create;
        Images[FIndex].Position:=0;
        FPicture.LoadFromStream(Images[FIndex]);
        if (not Terminated) then
          Synchronize(@ShowBitmap);
        FPicture.Free;
      end;
      2 : begin // libjpeg-turbo
        FPicture := TPicture.Create;
        FPicture.Bitmap.PixelFormat:=pf24bit;
        jpegDecompressor := tjInitDecompress();
        tjDecompressHeader2(jpegDecompressor, Images[FIndex].Memory,
Images[FIndex].Size, @jpegWidth, @jpegHeight, @jpegSubsamp);
        FPicture.Bitmap.SetSize(jpegWidth,jpegHeight);
        tjDecompress2(jpegDecompressor, Images[FIndex].Memory,
Images[FIndex].Size, FPicture.Bitmap.RawImage.Data, jpegWidth, 0,
jpegHeight, cint(TJPF_BGR), TJFLAG_FASTDCT);
        tjDestroy(jpegDecompressor);
        if (not Terminated) then
          Synchronize(@ShowBitmap);
        FPicture.Free;
      end;
    end;
    inc(FIndex);
    if (FIndex > high(Images)) then FIndex := low(Images);
  end;
end;

http://pasteboard.co/hlatrJG.png

Suggestions are welcome!

Sandro Cumerlato

Marc Weustink wrote 24 lines
Sandro Cumerlato wrote: > Hello Ara, my tests with libjpeg-/turbo/are even more promising. > > The following comparison between LCL and libjpeg-/turbo/ was made > decompressing for about one minute a sequence of several 4000x3000 JPEG > pictures. The results are expressed in "pictures per second" and prove > that libjpeg-/turbo/ is about 7-8 times faster than LCL: > How did you compare ? IE, whats the source ? Marc -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160418/4ccf18dc/attachment.html>

Reply by email

Aradeonas
to Sandro Cumerlato: I've used the attached header conversion for turbojpeg 1.4.2. It is incomplete, but quite…

Thank you very much for sharing. Clean.
I looked into it and its questioning for me how it works? Implementations like I mentioned is not like it and documentations and even dlls in here
http://www.libjpeg-turbo.org/Documentation/OfficialBinaries?are not like that.

Can you explain more?

Regards,
Ara

http://www.fastmail.com - The professional email service -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160418/801f864e/attachment.html>

Reply by email

Sandro Cumerlato
to Aradeonas

Hello Ara,
I'm using mingw-w64/msys2 binaries:

http://repo.msys2.org/mingw/i686/mingw-w64-i686-libjpeg-turbo-1.4.2-2-any.pkg.tar.xz http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-libjpeg-turbo-1.4.2-2-any.pkg.tar.xz

and libturbojpeg-0.dll included.

Best regards.

Sandro Cumerlato

Aradeonas wrote 23 lines
Thank you very much for sharing. Clean. I looked into it and its questioning for me how it works? Implementations like I mentioned is not like it and documentations and even dlls in here http://www.libjpeg-turbo.org/Documentation/OfficialBinaries are not like that. Can you explain more? Regards, Ara -- http://www.fastmail.com - The professional email service -- _______________________________________________ Lazarus mailing list http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160418/36187d1a/attachment.html>

Reply by email

Sandro Cumerlato
to Aradeonas

Hello Ara,

Aradeonas wrote
Thanks. I will test it.

Is there any particular reason that you didnt use official release?

I find convenient to use prebuilt binaries from the mingw-w64/msys2 toolchain, especially when I have to use several libraries within the same project.

Why there is much difference? It seems I miss something!

From README-turbo.txt:

libjpeg-turbo includes two APIs that can be used to compress and decompress JPEG images:

TurboJPEG API: This API provides an easy-to-use interface for compressing and decompressing JPEG images in memory. It also provides some functionality
that would not be straightforward to achieve using the underlying libjpeg API, such as generating planar YUV images and performing multiple simultaneous lossless transforms on an image. The Java interface for libjpeg-turbo is written on top of the TurboJPEG API.

libjpeg API: This is the de facto industry-standard API for compressing and
decompressing JPEG images. It is more difficult to use than the TurboJPEG API but also more powerful. The libjpeg API implementation in libjpeg-turbo
is both API/ABI-compatible and mathematically compatible with libjpeg v6b. It can also optionally be configured to be API/ABI-compatible with libjpeg v7
and v8 (see below.)

There is no significant performance advantage to either API when both are used
to perform similar operations.

Regards, Ara

Turbo demo binaries for both win32 and win64 are available at: http://www.djmaster.com/freepascal/demos/turbo.php

Best regards,
Sandro Cumerlato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160418/742507bb/attachment.html>

Reply by email

Aradeonas
to Sandro Cumerlato

Hi,

Thanks for explanation Sandro.
I checked your demo and even other demos and I can say they are interesting, I wish I had the source specially JPEG demo so I can check your results.

Regards,
Ara

http://www.fastmail.com - Does exactly what it says on the tin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160419/83fd87b0/attachment.html>

Reply by email