DDS Textures

Sage
Posts: 1,199
Joined: 2004.10
Post: #1
I had the good luck to find a link to a pile of DDS textures from NVIDIA the other day. They're pretty nice, and would save me some time making my own textures. Of course, they're not really public domain, but I'm just fooling around anyway.

http://developer.nvidia.com/object/IO_TTVol_01.html

I've found sample code to load them into OpenGL. The trouble is, I don't have a viewer which can view them. And I don't think photoshop ( on OS X at least ) will export DDS textures either.

So, I'm wondering if anybody knows of viewers for DDS, and if there are exporters for DDS either.

Secondly, if I go through the trouble of writing a loader, would anybody be interested if I wrote a quicklook plugin to display them?

Part of me thinks I might just be wasting my time. Wacko
Quote this message in a reply
Moderator
Posts: 1,562
Joined: 2003.10
Post: #2
I've been working on an image editor with DDS support planned, but I haven't written the I/O code for DDS yet. If you write a loader, I could definitely get some use out of it as a reference.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #3
The sample code I found was on mindcontrol.org ( the author a contributor to ODE ). That being said, it just unpacks the raw data into a struct reverse engineered from DX headers and passes it on to gl via glCompressedTexImage2D. So, even if I get it working, it's not a decompressor. GL is doing the work. And it wouldn't be any use for compressing, either.

I figure that if I wrote a QL plugin it would work by rendering the texture to an offscreen context and then use glReadPixels to fill an NSImage.
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #4
You guys might want to check out SOIL. I haven't tried it yet myself but it looks to have decent DDS support.

Edit: Almost forgot! There's the Squish framework and Graphic Converter has supported dds for a while now.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
Graphic Converter does *not* support DDS. It is unable to read valid DDS files, and unable to write valid DDS files.
Quote this message in a reply
Member
Posts: 53
Joined: 2007.08
Post: #6
I was able to use Graphic Converter to open the DDS files at the link TomorrowPlusX provided.

According to the website it should be able to import and export DDS. Are these somehow not valid?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
Well, maybe he's fixed it recently, but there was a long time when it claimed support, wrote corrupt files, and was unable to read correct files.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #8
Wow! SOIL looks frakking awesome.

I'd been planning to replace my use of libPNG with stb_image for a while... SOIL looks like a nice rational wrapper to stb_image. Awesome!
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #9
Hmm, Soil looks useful. Particularly, the stb_image_aug stuff. Though, would be nice if you could query for w,h, and components without the decode. They have the call in there but its not implemented.

Was using FreeImage. But I had some problems on Leopard and had to ditch it. They want to link against old sdks. Just seemed a little odd. Seems geared towards php. Not sure if it was a 64 vs 32 bit thing either.

Currently back to Quartz. Problem with this boils down to the CGBitmapContextCreate call. They just have to premultiply alpha. kCGImageAlphaLast does not seem to work and just get a black image. But kCGImageAlphaPremultipliedLast does. Thats fine in most cases. Problem is if I want to pass a gray scale map in the alpha channel to a glsl shader -- now I don't want premultiply! eg. using the alpha channel in a normal map. Yet, now you have to use another texture unit to get around the premultiply issue!

Hmm, sub out the Quartz and replace it with stb_image_aug stuff. Possible. Grin
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #10
That's exactly why I don't use Quartz for image loading. I have several bumpmap shaders which treat the normal map's alpha channel as a specular map. I could use another texture unit, but why?
Quote this message in a reply
Member
Posts: 320
Joined: 2003.06
Post: #11
Me too. premultiplied alpha is an outdated optimization that just pisses programmers off and does little good. GLSL is the main case where it's an annoyance, but it also causes an extra divide or multiply when creating and loading your own data buffers. Photoshop's lack of proper alpha support doesn't help matters much either.

Even worse is what Quartz does when loading PNGs with any of the gamma or other profiling chunks. It's dead easy to create a grey buffer all at 127, then save it, load it again and see all 110s or something. Just what people want. :/

Sorry, I always jump at the chance to rant about the stupidity of the image loading world Wink Don't get me started on color profiles.

Chopper, iSight Screensavers, DuckDuckDuck: http://majicjungle.com
Quote this message in a reply
Sage
Posts: 1,234
Joined: 2002.10
Post: #12
Guys, please file radars with your grievances about [Quartz, image loading, premultiplied alpha].

IMHO, if Quartz isn't going to support non-premultipled bitmap contexts, there ought to be a way to get canonical format data out of a CGImage without compositing it.
Quote this message in a reply
Member
Posts: 72
Joined: 2006.10
Post: #13
reubert Wrote:Even worse is what Quartz does when loading PNGs with any of the gamma or other profiling chunks. It's dead easy to create a grey buffer all at 127, then save it, load it again and see all 110s or something. Just what people want. :/

No offense, but if you are using a gamma-corrected format, how can you complain about it being gamma-corrected?
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #14
reubert Wrote:Me too. premultiplied alpha is an outdated optimization that just pisses programmers off and does little good.

Outdated? There are still good reasons to load (or save) textures with premultiplied alpha. It's the only good way that I know of to avoid fringes when scaling textures.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Member
Posts: 320
Joined: 2003.06
Post: #15
Granted, the real problem is that PNG even stores gamma information. Quartz pretty much had to observe PNG's stupidity.

Unfortunately every second application does not observe the gamma information, the quartz api gives no ability to ignore it or not, some applications (I'm looking at you photoshop) store gamma information but do not respect it on load, the gamma information stored could come from any number of places, including your monitor's color profile, some applications will acumulate the gamma information when converting between formats...

I use PNG because it compresses well, is widely supported, and handles alpha. There really aren't any alternatives. It's just a shame someone decided it would be a good idea to store gamma in the file.

Basically if I set my monitor to make everything look like it's on TV, then I want everything to look like TV. PNGs included. That the format thinks it should be able to override a user's monitor setting and look different to everything else is plain broken.

Chopper, iSight Screensavers, DuckDuckDuck: http://majicjungle.com
Quote this message in a reply
Post Reply