[osg-users] DDS with DXT1 with and without alpha

Robert Osfield robert.osfield at gmail.com
Thu Apr 14 05:16:16 PDT 2011

Hi Wojtek,

On Thu, Apr 14, 2011 at 12:23 PM, Wojciech Lewandowski
<lewandowski at ai.com.pl> wrote:
> I hope I do not spread misinformation, as I am not fully sure nor I know
> exact details but I believe that logic for finding if DXT1 pixels are
> transparent, should first check the order of entries in chunk( 4x4pixels)
> micropallete. And if its ascending then chunk may not contain alpha pixels
> and if its descending chunk may contain such pixels and then we should look
> for proper alpha pixel index.  That information comes from top of my head, I
> cannot at the moment delve deeper and look into verifying this but thats
> what I remember I read somewhere...

This only applies to RGBA variant of DXT1 (DXT1a), the RGB variant
(DTXc) has black pixel in
place of fully transpent pixels.   The links I provided discuss how
the format works,
and I'm pretty confortable with the actual DXT1 format now, and where
the problem lies.

The heart of the problem is that the DDS file format doesn't
distiguish between the
two varients of DXT1, there is an alpha bit in the DDS header that
could be used,
but 3rd party tools like nvdxt and nvcompress that write DDS files
don't set this bit
so both DTX1c with black encoded pixels and DTX1a are essentially identical
in terms of header and content.  Whether a particular file is DTX1a or DXT1c is
entirely implicit and only known by the creator of the imagery.


More information about the osg-users mailing list