View Full Version : Texture

01-24-2003, 01:52 PM
How do I load a gif/jpg/rgb/ppm file directly into texture memory.

01-24-2003, 02:12 PM
Use an image lib like DevIL: http://openil.sourceforge.net

01-24-2003, 03:07 PM
I work on Sun. I could not find a download version for sun. Is there not a way to do it usingopengl itself ?

01-24-2003, 03:11 PM
No, there isn't. And there shouldn't be; OpenGL is image file format agnostic.

01-24-2003, 03:30 PM
How about learning file IO using whatever language you program in for sun? If you know file IO programming then all you have to know then to load an image is the format. It's pretty easy after that.


01-24-2003, 03:44 PM
hmm, yeah that is pretty much what Iam doing now. Just thought that there may be an openGl implementation that Iam not taking advantage of.

Thanks guys

01-24-2003, 03:58 PM
Originally posted by quentapole:
I work on Sun. I could not find a download version for sun.

Use the source Luke. OpenIL is LGPL.

01-25-2003, 04:52 PM
You said gif and some people suggested that you use DevIL.

You should know that DevIL is not perfect when it comes to GIF. It has some kind of problem with animated GIFs. Also GIF support has been removed because the author was mislead into beleiving that Unisys holds patents over the GIF specification.

I also had problems with the DDS format. It has a bug so if you try to read a 3D texture, it says the number of slices is 1.

I don't know about the other file formats, but bugs are numerous.

01-25-2003, 06:30 PM
When you say mislead V-man, are you suggesting Unisys no longer holds the gif patent? I know Microsoft still posts a message on MSDN about how their license with Unisys for supporting gif files is not transferable to 3rd party developers. In other words, even though a given Microsoft api may support loading gif files, only Microsoft may use the functionality under the license. Third parties must obtain their own license with Unisys to use the functionality of the api. It would be my guess that DevIL was in the same kind of situation. Unless the gif patent has expired.

[This message has been edited by DFrey (edited 01-25-2003).]

01-26-2003, 08:00 AM

It was reported in Debian Weekly News based on a comp.compression thread, that the Unisys patent is set to expire in the USA on 20 December 2002 - 17 years (and 10 days) after it was granted. Most other sources claim the patent is due to expire in June 2003, 20 years after it was filed, but the 20 December camp say the 20 year rule only applies to patents granted after 1995.

01-26-2003, 06:37 PM
Originally posted by DFrey:
When you say mislead V-man, are you suggesting Unisys no longer holds the gif patent?
[This message has been edited by DFrey (edited 01-25-2003).]

They never held a patent on GIF. The last thing I heard was that GIF was created by CompuServe. At some point in time, it became possible to use the LZW compression in GIF.
Later on GIF became a popular format. Unisys complained at this point. They have been accused of keeping silent, waiting for it to gain popularity and then, kaching!

They have a patent on the compression method only. Luckily GIF can be stored uncompressed.

As for microsoft, they have a license (a very expensive one I imagine) and they document their API so that you can use it. Whether it's some kind of evil plot.. I dont know.

//Let me add that libpng and perhaps other free image libs (targa) (I think Devil uses them) also depend on a library called libz.
libz uses the LZW compression scheme illegally.

So watch out!

[This message has been edited by V-man (edited 01-26-2003).]

01-26-2003, 09:11 PM
Zlib uses deflate, which is (AFAICT) an LZ77 algorithm, which is a class widely believed to be free from patent encumberance of the type "enjoyed" by GIF.

In fact, this is one of the major reasons ZIP and gzip have become the standard, rather than the LZ78 based compress, or other similar algorithms (such as AP).

01-27-2003, 05:39 PM
I think I was visiting one the of web pages for libtiff (or maybe for targa) and I remember seeing on the main page about the zlib containing the LZW and how they planned on switching to a new version of zlib as soon as it was hatched.

Well, it's up to them to correct it if it's true.