Stripping the image libraries

What it says on the tin: a place to discuss proposed new features.
Post Reply
User avatar
liberator
Greenskin
Posts: 117
Joined: Mon Jan 24, 2005 2:27 pm
Location: Sillicon Valley, California
Contact:

Stripping the image libraries

Post by liberator »

Hi,

Ogre has a number of dependancies that I rather dislike because i'm working on integrating Ogre into my platform. DevIL is basicly manditory for example. My platform has it's own image creation/loading capabilities and redundant libraries is never a good thing.

I would like to request an added configuration switch in the Ogre config file that strips all implementations except the base classes.
example:

#define USE_DEVIL_FOR_IMAGE_LOADING 0

or something to that effect.
This "feature" can be added in like 10 minutes so I hope you give it some thought.

Tnx. in advance.
User avatar
temas
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 390
Joined: Sun Oct 06, 2002 11:19 pm
Location: The Woodlands, TX
Contact:

Post by temas »

If you've already looked at how to do it we would love a patch to more fully consider it.
User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands
x 1

Post by :wumpus: »

It's very easy to use your own codecs for loading images; don't compile in ILCodecs and ILImageCodec, remove the calls from Ogre::Root and you're done. (you can easily manually register codecs; see EXRCodec in the plugins folder)

You would still need some other library to do image operations like scaling though. You need to change parts in OgrePixelFormat.cpp and Image.cpp for that. (assuming HEAD)
User avatar
liberator
Greenskin
Posts: 117
Joined: Mon Jan 24, 2005 2:27 pm
Location: Sillicon Valley, California
Contact:

Post by liberator »

:wumpus: wrote:It's very easy to use your own codecs for loading images; don't compile in ILCodecs and ILImageCodec, remove the calls from Ogre::Root and you're done. (you can easily manually register codecs; see EXRCodec in the plugins folder)

You would still need some other library to do image operations like scaling though. You need to change parts in OgrePixelFormat.cpp and Image.cpp for that. (assuming HEAD)
My image module is largely compatible so the format adaptation is no problem. It was made for my own renderer, I recently decided to stop devving it and use Ogre as the renderer instead.

The changes you suggest is exactly what I did, however a switch to remove support for specific dependancies would be alot cleaner imho. Since Ogre is a renderer I myself don't see the need for manditory dependancies on recource handling implementations.
An abstract interface with an optional implementation will be more then sufficient imho.
User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands
x 1

Post by :wumpus: »

Better seperation of the image loading is a post-1.0 issue as I don't have time. I'd really like our own scaling implementation (the DevIL one is slow, and broken for floating point images anyway), so that the only dependency on DevIL will be the image loading/saving. In which case we could easily implement your suggestion of an #ifdef that disables the OgreILCodecs.

This scaling function will need to scale any 1d,2d or 3d pixel box to another 1d,2d,3d pixel box, and work with both float and byte oriented formats with 1(L),2(LA),3(RGB) or 4(RGBA) channels. (like iluScale) Especially 1d/2d->1d/2d scaling for byte formats should be fast. THe others may be slow as long as they work. You don't have to support packed pixel formats like PF_R10G10B10A2 and PF_R3G3B2 (those will be converted to an intermediate byte or float format and back via PixelUtil::bulkPixelConversion).

I don't have time to implement such a function now. If your image library has one we can easily adapt I'd really like that, and we can even roll this in before 1.0.
qsilver
OGRE Community Helper
OGRE Community Helper
Posts: 198
Joined: Sat Oct 02, 2004 9:11 am
Location: San Francisco, California, USA

Post by qsilver »

:wumpus: wrote:Better seperation of the image loading is a post-1.0 issue as I don't have time. I'd really like our own scaling implementation...
That sounds like a challenge ;) I need to learn a bit more about filtering, and this code will need careful tuning for performance, so it's a good excuse for me to get off my butt.
This scaling function will need to scale any 1d,2d or 3d pixel box to another 1d,2d,3d pixel box, and work with both float and byte oriented formats with 1(L),2(LA),3(RGB) or 4(RGBA) channels. (like iluScale) Especially 1d/2d->1d/2d scaling for byte formats should be fast. THe others may be slow as long as they work. You don't have to support packed pixel formats like PF_R10G10B10A2 and PF_R3G3B2 (those will be converted to an intermediate byte or float format and back via PixelUtil::bulkPixelConversion).
I'll see what I can do. Should I stick to straight C/C++, or may I also attempt inline assembler with #ifdef protection? I need an excuse to learn about SSE and all that jazz.
User avatar
liberator
Greenskin
Posts: 117
Joined: Mon Jan 24, 2005 2:27 pm
Location: Sillicon Valley, California
Contact:

Post by liberator »

You can't use the code in my platform because I made it for something work related and thus I don't own the copyright.
I will have to replace that scale functionality with my own code sometime but I simply don't have the time at the moment, sorry.
User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands
x 1

Post by :wumpus: »

qsilver wrote: That sounds like a challenge ;) I need to learn a bit more about filtering, and this code will need careful tuning for performance, so it's a good excuse for me to get off my butt.
It's a challenge indeed; but there are good sides to it: For scaling, you can regard an RGBA image as four greyscale images at offsets (same for 2,3 channels) so that already drops complexity to six cases:
1D, byte (fixed point)
2D, byte (fixed point)
3D, byte (fixed point)
1D, float
2D, float
3D, float

I'd like bilinear filtering. In the 2D case this means you get the four pixels around the target pixel (integer part), and interpolate between those four according to the subpixel position (fraction) yielded by the scaling. (in the 1D case you only have to interpolate between 2 pixels, in the 3D case between 8 )
DevIL does this very inefficiently by using floating point math, and calculating the fractions for every pixel. (that's a lot of multiplications).
Most of the multiplications can even be eliminated by using fixed point, masks, and incrementing values intelligently and moving calculations out of the inner loop.
I'll see what I can do. Should I stick to straight C/C++, or may I also attempt inline assembler with #ifdef protection? I need an excuse to learn about SSE and all that jazz.
Thanks! You should best stick to plain C++ first and make that as fast as possible; this makes sure it works good on all platforms. If you want, you can give assembly a try later on but as cross-platformness is very important for us it isn't a priority.
qsilver
OGRE Community Helper
OGRE Community Helper
Posts: 198
Joined: Sat Oct 02, 2004 9:11 am
Location: San Francisco, California, USA

Post by qsilver »

User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands
x 1

Post by :wumpus: »

This is now in -HEAD.
# Ogre does not depend on DevIL anymore internally, if you provide your own image loading codecs. In case of windows, just define OGRE_NO_DEVIL and remove OgreIL* from your build system. In case of Linux, use ./configure --disable-devil .
Post Reply