Why FreeImage? Linux issues.

zap · Post by **zap** » Thu Oct 19, 2006 12:35 am

Risking to be beaten to death by the Ogre guys, I'll still rise this question:

WHY FREEIMAGE?

FreeImage is big. 500k *just* the pure FreeImage code. A little too much for just image loading functions (yes, I know it can do more, but Ogre doesn't use that anyway).

FreeImage is inflexible. You can't configure it to support just the image formats you need, you have to take all the 23 formats or die (or start hacking).

FreeImage carries with it a modified copy of libjpeg, libtiff, libpng. It also carries with it a copy of zlib and libmng. Those libraries are *required* to be used, you can't use the system-wide zlib, libjpeg, libtiff, libmng, libpng.

I hope at least linux users will understand how ugly is this, windows users are pretty used to the approach when every program carries his own zlib with it. With these libraries FreeImage is 1.5Mb large.

FreeImage has a lot of functionality that Ogre doesn't need. This is like using a excavator to hammer a nail.

The only answer to the question in subject I see is the licensing issue. FreeImage is not LGPL, which if I understand correctly is a no-no on game consoles.

If it is so, then FreeImage could be left as a option to those who want to use it, and for those who don't want it there could be an alternative image codec implementation. In fact, I propose to use by default on Linux some alternative image loading library, one of those that are already installed on most Linux distributions.

I can implement a ImageCodec that uses either one of:

- SDL_image (34k shared library, supports BMP, PPM, PCX, GIF, JPEG, PNG).
- gd (250k shared library, supports BMP, PNM (PPM/PGM/PBM), XPM, LBM, PCX, GIF, JPEG, PNG, TGA, and TIFF formats).
- maybe directly libpng/libjpeg

Then --disable-freeimage can be made default on Linux, so Ogre will work out-of-the-shelf for all Linux users.

Post by **pjcast** » Thu Oct 19, 2006 1:28 am

/me resists beating you to death.. j/k

Answers are pretty simple.

Why FreeImage? Because FreeImage does not have the license restrictions that DevIL does, and it can be used on Consoles - as part of making Ogre have a dual license itself.

FreeImage is big? Well, FreeImage just contains all the codecs that DevIL uses, so I don't know if it is that much bigger. Ogre uses both encoding and decoding of the lib.

I'm not really sure why FreeImage does not use system wide lib's instead of including it's own. Probably to make distribution much much simpler. Just include the FreeImage shared lib where ever you go. And, I think FreeImage was first started on Windows, so they probably used that philosohpy.

You can disable FreeImage and use your own if you so desire. The same was true for DevIL in Dagon. In fact, you could always port DevIL codecs back into Ogre if you choose. Or, register your own when your app starts up.

DevIL's main bad points were: license being LGPL.. And, DevIL development was slow with patches not being incorporated.

Post by **nfz** » Thu Oct 19, 2006 4:16 am

You can build FreeImage to use the shared zlib. I am using the zlib1.dll for the Code::Blocks + MinGW build of FreeImage for Eihort with no problems. It seemed a waste for FreeImage to have its own static build of zlib when Ogre is using the dll version so I changed the build settings for FreeImage and associated image libs (no code changes were required).

Since I also support Ogre 1.2.3 C::B + MinGW SDK which uses Devil, I use the same static image libs when building both Devil and FreeImage. No sense in building the image libs twice. I never compared the sources between what was included with FreeImage and what I got from the respective image lib websites but so far I haven't run into any problems and no users have complained yet

.

I haven't tried doing the same on linux yet but I don't foresee a problem modifying the makefile to make use of the shared libs.

zap · Post by **zap** » Thu Oct 19, 2006 7:28 am

As I said, it contains a modified copy of the libjpeg, libtiff and libpng so you can't use any other copy. The changes are minimal, still they make it incompatible. And I understood from the author that this is the official position that isn't going to change - "Each FreeImage version is developped, tested and designed to run with a particular set of third party libraries, each library being configured with a particular set of options. Each new FreeImage release takes into account the changes log published by each third party library : this way, the FreeImage code and it's underlying libraries are always up-to-date regarding bugs and security issues. Thus, the third party code may be different from the 'official release code'used by Linux OS.".

I took a look at what image loading libraries are supported by CEGUI and found yet another excellent alternative to FreeImage: Corona (http://corona.sourceforge.net/) is licensed under the zlib license, which basically means you can do with it whatever you like. Besides, Ogre already depends on zlib so it should not be an issue. The library is pretty small (60k), offers BMP, GIF, JPEG, PCX, PNG, TGA format read/write support, has a simple C++ API and its own namespace.

A option could be added to configure "--with-image-codec=xxx" that would accept a list of image codecs to support (for example --with-image-codec=freeimage,sdl,dds); by default it will look for all supported image loading libraries. This way it will allow for transparent detection of whatever image library the user has installed. And the --without-freeimage switch could be removed.

So how about a new image codec? Personally my choice would be SDL_image since it supports lots of pixel formats including grayscale and 16-bit RGB. It doesn't support save but that's not a big issue for most people I think. Besides, its not a big deal to write a specific writer for some simple format, or even for libpng/libjpeg.

Post by **sinbad** » Thu Oct 19, 2006 2:50 pm

To be honest, I'm glad they use a local copy of the base image libs. Have you any idea how many Linux people we've had in here complaining that DevIL doesn't work, and the reason is that they built it with incompatible versions of the base libs, or versions which had bugs, etc? Way too many times. The flexibility of local shared base libs on Linux cuts both ways.

You have the licensing issue backwards. FreeImage's license (FreeImage Public License) is perfectly compatible with consoles - it's the LGPL that generally isn't.

I looked at Corona but ruled it out. It hasn't been updated in 3 years, and that was exactly the problem we had with DevIL, bugs were just not fixed in the main release. We need something that's actively developed & supported. It also has no proven OSX support, and it doesn't support as many formats, especially for writing. Taking screenshots as JPEG is not possible for example.

If you have suggestions for FreeImage I suggest you approach them. It was simply the best ooption when considered in the round - you might not agree with that but hey, we all have our own positions and a choice has to be made.

zap · Post by **zap** » Thu Oct 19, 2006 10:19 pm

It seems you're right. FreeImage is the best giveaway image library of this type I could find on the net. There are tons of such libraries, but most of them are (L)GPL. I found some non-LGPL libraries, but they are much larger than FreeImage and provide much more (unused functions).

Is there any problem to include a optional image codec for a LGPL library like SDL_image? If a developer compiles Ogre without SDL support, it will not be forced to obey LGPL.

And about carrying a local copy of libraries... that's why I want to use a mainstream library like SDL_image or gd or gdk_pixbuf or anything that's well supported and widely used. These kinds of problems (like library incompatibilities) are solved behind the scene, so I just can use the system libraries which are guaranteed 100% working.

And the thing you say DevIL doesn't work with incompatible libs... well it's DevIL's fault. It should check the used library version and complain if it doesn't like it either during configure or even compilation stage. It isn't a fault of the shared library system.

Kentamanos · Post by **Kentamanos** » Thu Oct 19, 2006 10:52 pm

Do most of the "mainstream" libraries include DDS support?

Post by **sinbad** » Thu Oct 19, 2006 11:35 pm

zap wrote:Is there any problem to include a optional image codec for a LGPL library like SDL_image? If a developer compiles Ogre without SDL support, it will not be forced to obey LGPL.

Sure, you can turn off FreeImage in OgreConfig.h or just use --disable-freeimage in your ./configure, and register your own codecs instead (via Codec::registerCodec), it's all pluggable.

Kentamanos wrote: Do most of the "mainstream" libraries include DDS support?

Unfortunately not. Many don't include it at all, and those that do often don't implement it completely or have some issues. DevIL had bugs with embedded mipmaps, FreeImage doesn't have a good way to leave the data compressed which is needed for GL (and it's actually a design issue rather than something that's easily changed, the API structures would have to change to support it hence why I didn't try to patch it).

In the end writing my own DDS codec was the best option.