# Integration with Vampyre Imaging Library, new example image\_display to test image loading speed and format support
**URL:** https://forum.castle-engine.io/t/integration-with-vampyre-imaging-library-new-example-image-display-to-test-image-loading-speed-and-format-support/476
**Category:** News
**Created:** [December 18, 2021, 3:10pm UTC](https://forum.castle-engine.io/t/integration-with-vampyre-imaging-library-new-example-image-display-to-test-image-loading-speed-and-format-support/476 "2021-12-18T15:10:02Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [December 18, 2021, 3:10pm UTC](https://forum.castle-engine.io/t/integration-with-vampyre-imaging-library-new-example-image-display-to-test-image-loading-speed-and-format-support/476/1 "2021-12-18T15:10:03Z")
| [](https://castle-engine.io/wp/wp-content/uploads/2021/12/ex_image.png "Castle Game Engine example - image\_display") |
| [](https://castle-engine.io/wp/wp-content/uploads/2021/12/Zrzut-ekranu-z-2021-12-18-15-50-37.png "examples/images\_videos/image\_display speed test") |
We now can use [Vampyre Imaging Library](https://imaginglib.sourceforge.io/) to load and save images in various formats. After some testing, I’m _very_ impressed with how easy it is to use Vampyre, and we are already:
- **Using it with _Delphi_ by default (no need to do anything)**.
- Vampyre source code is bundled with CGE, so you don’t need to set up / download anything extra. Vampyre is just automatically used under the hood by CGE to load/save some image formats. It is in [src/vampyre\_imaginglib of CGE](https://github.com/castle-engine/castle-engine/tree/master/src/vampyre_imaginglib), and CGE build tool automatically passes paths to it when building CGE applications.
**For FPC** :
I have also tested using Vampyre with _FPC_, and our [build tool](https://github.com/castle-engine/castle-engine/wiki/Build-Tool) already contains the necessary paths. Every FPC user of CGE can just define `USE_VAMPYRE_IMAGING` symbol to use it. There are a number of ways to define it, the advised is to [define it in CastleEngineManifest.xml, like here](https://github.com/castle-engine/castle-engine/blob/master/examples/images_videos/image_display/CastleEngineManifest.xml).
In the near future we will likely just use Vampyre with _FPC_ by default, so the need to define `USE_VAMPYRE_IMAGING` is just a temporary thing. We just need more testing, with various FPC versions and platforms (see lower for examples).
In the more distant future, we may also remove the code to use _FpImage_ with _FPC_, even as a fallback, since Vampyre seems just better than _FpImage_ in every way.
**Advantages of using Vampyre** :
- _Vampyre Imaging Library_ is cross-platform.
- Works with both FPC and Delphi. Unlike FPC-specific _FpImage_ or Delphi-specific _PngImage_ (and other stuff in Delphi `Vcl.Imaging`).
- Supports many image formats, both reading and writing. It even supports a bit more than _FpImage_, e.g. we added now loading TIFF, JPEG 2000, XPM without any extra tools.
- It has really good and simple API. Almost entire [CGE + Vampyre integration code is in this include file](https://github.com/castle-engine/castle-engine/blob/master/src/images/castleimages_vampyre_imaging.inc).
- It is well documented on [https://imaginglib.sourceforge.io/](https://imaginglib.sourceforge.io/) , with [manual](http://galfar.vevb.net/imaging/doc/imaging.html) and [reference](http://galfar.vevb.net/imaging/doc/RefDoc/toc.html).
- It is efficient. Unlike e.g. _FpImage_ from FPC — which turned out to be very inefficient when it comes e.g. to PNG image reading (despite our efforts to make it fast, using `TFPCompactImgRGBA8Bit`, using format detection in `InternalDetectClassPNG`).
- It doesn’t require any external libraries. Unlike LibPng approach in CGE.
**Help us test!**
I’m eager to hear about your tests of Vampyre on various platforms, with various compilers, with your images.
You can use e.g. our [castle-view-image (image viewer)](https://github.com/castle-engine/castle-view-image) for easy testing. It compiles now with both FPC and Delphi.
You can also use a new cross-platform example: [examples/images\_videos/image\_display](https://github.com/castle-engine/castle-engine/tree/master/examples/images_videos/image_display) . This loads the image in a number of formats (making sure we support them all), and can perform speed testing – to compare loading times of various libraries, so you can verify the speed of Vampyre vs FpImage vs LibPng yourself.
What about LibPng, DDS, KTX?
Vampyre is still a bit slower for reading PNGs than LibPng (about 2x slower on Linux/x86\_64, which is anyway better than FpImage that was 4x slower), so we will keep relying on LibPng for PNG. Still, Vampyre is a much better fallback than FpImage when LibPng will be missing.
We may rely on Vampyre for some formats that are currently built-in in CGE code, too. This includes BMP, RGBE, PPM.
We will likely keep our own CGE code for loading [DDS](https://castle-engine.io/x3d_implementation_texturing.php#section_dds) and [KTX](https://castle-engine.io/x3d_implementation_texturing.php#section_ktx) though. (Vampyre can handle DDS. But we want DDS and KTX to go though a similar code path in CGE, and we want to efficiently use all their features — cubemaps, texture compression, 3d textures, mipmaps.)
---
### Author:  [@Arioch](https://forum.castle-engine.io/u/Arioch)
#### Post date: [January 12, 2022, 9:44pm UTC](https://forum.castle-engine.io/t/integration-with-vampyre-imaging-library-new-example-image-display-to-test-image-loading-speed-and-format-support/476/2 "2022-01-12T21:44:09Z")
While i “traditionally” used GraphicEx for formats and Graphics32 for transparent 2D, i heard Vampyre was a strong competitor.
That said
> E.g. it is necessary for JPG support in Delphi.
???
XE2 Delphi support JPEG and PNG out of the box, actually VLC.jpeg i think was already there in Delphi 5 in 1999
* * *
I wonder how having local copy would work long term… In my experience separating yourself from upstream changes history makes it harder long-term, if you would need to co-develop that library, at least to find and fix bugs in it. One time convenience, sure… But maybe you could just add dependency from GCE’s packages to Vampyre’s package.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [January 12, 2022, 11:22pm UTC](https://forum.castle-engine.io/t/integration-with-vampyre-imaging-library-new-example-image-display-to-test-image-loading-speed-and-format-support/476/3 "2022-01-12T23:22:36Z")
> [@Arioch](#):
>
> > E.g. it is necessary for JPG support in Delphi.
>
> ???
>
> XE2 Delphi support JPEG and PNG out of the box, actually VLC.jpeg i think was already there in Delphi 5 in 1999
I didn’t mean that JPEG or PNG support without Vampyre is impossible for Delphi. I meant that, in CGE, using Vampyre is now the only implemented way to support JPEG.
As for `Vcl.Imaging.Jpeg` from Delphi [Vcl.Imaging - RAD Studio API Documentation](https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Imaging) : While it is indeed coming with Delphi out-of-the-box and allows to use JPG with `TGraphic` and rest of VCL, it isn’t useful in CGE. There’s no way to extract image data efficiently, without going through `TGraphic` drawing routines.
This is unlike `Vcl.Imaging.PngImage`, which does allow to extract raw image contents, and we implement support for it in CGE for now, as a fallback if you deactivate Vampyre. (I said “right now”, because we may remove this fallback at some point – as Vampyre works great, we may just rely on it even more in the future.)
> [@Arioch](#):
>
> I wonder how having local copy would work long term… In my experience separating yourself from upstream changes history makes it harder long-term, if you would need to co-develop that library, at least to find and fix bugs in it. One time convenience, sure… But maybe you could just add dependency from GCE’s packages to Vampyre’s package.
People get CGE code in various ways, for Lazarus, for Delphi, using zip, using GIT from GitHub, using OPM… And more ways will come. Like Delphi GetIt and Delphinus. So bundling Vampyre inside CGE is just the most reliable way that doesn’t introduce headaches / additional steps for some workflows.
As for synchronizing with Vampyre upstream: that’s true, this is a concern. Let’s just see how active the upstream of Vampyre will be and how much effort will the synchronization cost. The synchronization right now can be done with a script, and if needed we can just tell Jenkins in the future to do it (and test it) automatically and regularly.