Fast image loading/display

[Wilford]

I just imported a Delphi project into Lazarus that does a lot of image loading and display.  The project compiled in Lazarus is very noticeably slower than when compiled in Delphi where image loading is concerned.

So I'm wondering what my options are.  First of all I'm using TPicture.LoadFromFile to do the image loading.  If for some reason that's no longer the way I should be doing it in Lazarus I can change it.

I saw the list of Graphics libraries at http://wiki.lazarus.freepascal.org/Graphics_libraries, but I'm not sure if that's the direction I need to go or not.  If so, I'd like to get some suggestions on which might be the best for my needs.  I'm not doing any fancy alterations or manipulations on the images.  I just need to load and display them quickly.  I do need to be able to resize them though, that's the one caveat I suppose.

Ideally I'd like to get the TPicture.LoadFromFile working faster rather than having to write a bunch of code to load each specific file type that might come up.

Oh I should mention I've only tested JPEG images so far.  I suppose I should check some PNGs to see if the problem is JPEG specific.  Either way, I'll need to make some changes or the project won't work in Lazarus.

[Wilford]

As a test I wrote a program that loads and displays a very large JPEG (http://en.wikipedia.org/wiki/File:The_Garden_of_Earthly_Delights_by_Bosch_High_Resolution.jpg).  Compiled in Delphi it took around 35 seconds.  With Lazarus it took around 54 seconds.  So yeah a pretty big difference.  Since I'm not getting any replies I guess I'll have to just start working my way down the list of third party libraries and try them until I find something that helps.

[BigChimp]

Wilford,

I seem to remember FPC or Lazarus mailing list discussions about the image code not benig very fast. Sorry, can't remember more...

[Wilford]

I seem to remember FPC or Lazarus mailing list discussions about the image code not benig very fast. Sorry, can't remember more...

Yes I found this:

fcl-image is written for maximal portability and maintainability and is quite slow.

from here: http://wiki.lazarus.freepascal.org/fcl-image, so apparently this is by design.  Unfortunately so far I haven't found a better solution.

My first go was to use the Vampyre Imaging Library listed on the graphics libraries page.  Unfortunately it ran out of memory and crashed every time it tried to load my large test image.

So I resized my testing image down to half original size and it was able to handle that.  In my testing the default graphics libraries used by Lazarus loaded that image in a little over 7 seconds, and displayed it in 1.5 seconds.

The Vampyre Imaging Library loaded it slightly faster, a little over 6 seconds, but it took around 2.5 seconds to display, so no net gain.

Unfortunately it doesn't look like there are many other options for me to try.  I'll keep at it but I'm starting to suspect that what I want may just not be possible with Lazarus.

[circular]

Maybe it would be possible to optimize loading functions, but this could take a huge time to code it. If you have some time, you may have a look at FreePascal loading functions and track for slowness.

[eny]

My first go was to use the Vampyre Imaging Library listed on the graphics libraries page.  Unfortunately it ran out of memory and crashed every time it tried to load my large test image.

Handling jpegs of 100MB is rather extreme (even Gimp takes a couple of minutes to recover when I try loading that image; PSP Photo XI does a better job).

In general I'm fairly happy with Vampyre because it outperforms Lazarus in displaying speed (the main reason why I use it in a photo mgmt application).
Loading speed is comparable.
Attached a sample of the time it took to load and display an image half the dimensions (approx. 30MB).
The numbers are the Windows tick counts in milliseconds.

[Wilford]

I do have a bit of good news to report.  I neglected to take into account that the Vampyre library automatically takes over JPEG loading just by including the units in the uses clause.  So what I was testing wasn't Vampyre versus default, I was really testing Vampyre versus Vampyre with different loading and display methods.

Going back and testing some more it looks like Vampyre is actually handling the images in about 80% of the time the default code does.  That's not bad.  It's enough to be noticeably faster.

It's still not as fast as the Delphi version, but if I remember correctly Delphi links a highly optimized binary for JPEG loading, so I don't think there's any way a loader written completely in a high level language will be able to compare to that for speed.  So until someone creates something like that for all platforms Lazarus supports, what I'm seeing now is probably as good as it's going to get.  I think I can work with it.

[User137]

Just curious, but isn't Lazarus internally handling every image with 16 bits per color channel? It's what TRawImage uses in its color functions. Because if it is so, i'm really wondering why have that big "portability"? 64 bits for RGBA is really wild use of memory that would have uses only in very extreme graphics applications. I assume even Adobe Photoshop and Gimp can manage with 32 bits.

[Blaazen]

I assume even Adobe Photoshop and Gimp can manage with 32 bits.

AFAIK 8-bit per channel is considered as web-graphic (good, but not proffesional). GIMP supports it now but support for more than 8 bits per channel is planned (using GEGL).
PhotoShop works with both 8/16 bits per channel.
Some applications, like CinePaint, support 32-bit floating point per channel.

[felipemdc]

Just curious, but isn't Lazarus internally handling every image with 16 bits per color channel?

Not every image. Only when loading from a file/stream, or saving, because loading/saving goes through fcl-image image readers/writers.

It's what TRawImage uses in its color functions.

TRawImage has no painting functions and it supports all common pixel formats and really uses them for internal storage. TLazCanvas for example has painting functions and it can be used together with TRawImage (via TLazIntfImage) so it can draw directly to any of the most common pixel formats.

That's what powers LCL-CustomDrawn, and here I use many different pixel formats to match better what each platform prefers.

Because if it is so, i'm really wondering why have that big "portability"? 64 bits for RGBA is really wild use of memory that would have uses only in very extreme graphics applications. I assume even Adobe Photoshop and Gimp can manage with 32 bits.

Someone made a decision many years ago and changing this now would be a huge work because all image readers/writers would need to be updated. If one changes without updating them, then the change is useless, if you want a flexible storage and painting just use TRawImage+TLazIntfImage+TLazCanvas

[theo]

If you need to produce smaller images, you could do it similar to what I did in my thumbviewer:

http://www.theo.ch/lazarus/thumbview.zip

It loads your 97MB Bosch in less than 10 seconds, but already resized!

Not sure if this helps.

If you want to try it: Install the lpk, place a TThumbControl on a form (it's in the "misc" tab), and set the "directory" property to the folder of your bosch.

[PeteS]

Theo,

I've just tried your ThumbControl, looks good and loads/displays quickly especially in MultiThreaded mode ... but the scroll bars don't work when I have hidden images (more than the visual capacity of the display)?  I've tried all options of Layout, no luck - scroll bars can be moved but they don't scroll the thumbnails and when released jump back to the initial positions.  What am I doing silly?  Win7, 64-bit, 0.9.30/2.4.2 

[theo]

I am unable to reproduce your problem

Tested on :

Lazarus 0.9.31 r34308 FPC 2.5.1 i386-win32-win32/win64
Lazarus 0.9.31 r34321M FPC 2.4.4 x86_64-linux-gtk 2
Lazarus 0.9.31 r34321M FPC 2.4.4 x86_64-linux-qt

[PeteS]

OK, at home on WinXP, 32-bit, 0.9.29/2.4.3 there is no problem at all - works as expected.  Guess it's time to update the 64-bit Laz/FPC version.

Many thanks, Happy Holidays!