Re: [osg-users] DDS with DXT1 with and without alpha
Hi Mikhail, I think you have mis-intrepted my suggestion that DTX1a and DTX1c have essential the same header and contents - I mean in that they are the same format in memory so we can't distinguish between the two. One would not expect nvcompress to produce the same output for DXT1a and DTX1c and I didn't mean to imply that it or any other tool would. Instead I meant to infer that such a tool that generated a DTX1a image with transparent pixels could be identical to a DTX1c image with black pixels. Robert. On Thu, Apr 14, 2011 at 1:34 PM, Mikhail I. Izmestev wrote: > 14.04.2011 16:16, Robert Osfield wrote: > >> 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. > > Where from this information? > > $ nvdxt.exe -nomipmap -dxt1a -file test_dxt1.png -output test_dxt1a.dds > Version 8.30 > Reading test_dxt1.png [Processing] Writing .\test_dxt1a.dds > > $ nvdxt.exe -nomipmap -dxt1c -file test_dxt1.png -output test_dxt1c.dds > Version 8.30 > Reading test_dxt1.png [Processing] Writing .\test_dxt1c.dds > > $ md5sum.exe test_dxt1*.dds > ac1473f8822abbb2d6006de0021c6bc0 *test_dxt1a.dds > 249071d0b0974593b310656acea73e1d *test_dxt1c.dds > > Mikhail > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS with DXT1 with and without alpha
14.04.2011 16:43, Mikhail I. Izmestev пишет: 14.04.2011 16:34, Mikhail I. Izmestev wrote: 14.04.2011 16:16, Robert Osfield wrote: 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. Where from this information? $ nvdxt.exe -nomipmap -dxt1a -file test_dxt1.png -output test_dxt1a.dds Version 8.30 Reading test_dxt1.png [Processing] Writing .\test_dxt1a.dds $ nvdxt.exe -nomipmap -dxt1c -file test_dxt1.png -output test_dxt1c.dds Version 8.30 Reading test_dxt1.png [Processing] Writing .\test_dxt1c.dds $ md5sum.exe test_dxt1*.dds ac1473f8822abbb2d6006de0021c6bc0 *test_dxt1a.dds 249071d0b0974593b310656acea73e1d *test_dxt1c.dds Mikhail Attach files to previous message. Mikhail I'm sorry, In DDS header really no alpha flag, my mistake :) $ nvdxt.exe -nomipmap -alpha -dxt1a -file test_dxt1_a.png -output test_dxt1a_a.dds Version 8.30 Reading test_dxt1_a.png [Processing] Writing .\test_dxt1a_a.dds $ nvdxt.exe -nomipmap -dxt1c -alpha -file test_dxt1_a.png -output test_dxt1c_a.dds Version 8.30 Reading test_dxt1_a.png [Processing] Writing .\test_dxt1c_a.dds Mikhail. test_dxt1c_a.dds Description: Binary data <> test_dxt1a_a.dds Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS with DXT1 with and without alpha
14.04.2011 16:34, Mikhail I. Izmestev wrote: 14.04.2011 16:16, Robert Osfield wrote: 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. Where from this information? $ nvdxt.exe -nomipmap -dxt1a -file test_dxt1.png -output test_dxt1a.dds Version 8.30 Reading test_dxt1.png [Processing] Writing .\test_dxt1a.dds $ nvdxt.exe -nomipmap -dxt1c -file test_dxt1.png -output test_dxt1c.dds Version 8.30 Reading test_dxt1.png [Processing] Writing .\test_dxt1c.dds $ md5sum.exe test_dxt1*.dds ac1473f8822abbb2d6006de0021c6bc0 *test_dxt1a.dds 249071d0b0974593b310656acea73e1d *test_dxt1c.dds Mikhail Attach files to previous message. Mikhail test_dxt1a.dds Description: Binary data test_dxt1c.dds Description: Binary data <>___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS with DXT1 with and without alpha
14.04.2011 16:16, Robert Osfield wrote: 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. Where from this information? $ nvdxt.exe -nomipmap -dxt1a -file test_dxt1.png -output test_dxt1a.dds Version 8.30 Reading test_dxt1.png [Processing] Writing .\test_dxt1a.dds $ nvdxt.exe -nomipmap -dxt1c -file test_dxt1.png -output test_dxt1c.dds Version 8.30 Reading test_dxt1.png [Processing] Writing .\test_dxt1c.dds $ md5sum.exe test_dxt1*.dds ac1473f8822abbb2d6006de0021c6bc0 *test_dxt1a.dds 249071d0b0974593b310656acea73e1d *test_dxt1c.dds Mikhail ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS with DXT1 with and without alpha
Hi Wojtek, On Thu, Apr 14, 2011 at 12:23 PM, Wojciech Lewandowski 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. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS with DXT1 with and without alpha
Hi Robert,
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...
Cheers,
Wojtek Lewandowski
-Oryginalna wiadomość-
From: Robert Osfield
Sent: Thursday, April 14, 2011 1:03 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] DDS with DXT1 with and without alpha
Hi All,
I have now implemented the various options I suggested in my previous
post, and for now have opted to default to DXT1 RGB pixle format for
DXT1 files, unless the alpha bit in the dds header is set, then it
will choose DXT1 RGBA pixel format. The OSG's DDS plugin does set the
alpha bit when writting out DXT1 RGBA images, but other 3rd party
tools such as nvcompress do not, so for these 3rd party generated
images the dds plugin will now read all these DXT1 files as RGB.
These changes are now checked into svn/trunk.
You can list the new options using:
osgconv --format dds
Which will output:
Plugin osgPlugins-2.9.12/osgdb_dds.so
{
ReaderWriter : DDS Image Reader/Writer
{
features : readObject readImage writeObject writeImage
extensions : .ddsDDS image format
options: dds_dxt1_detect_rgbaFor DXT1 encode images
set the pixel format according to presence of transparent pixels
options: dds_dxt1_rgbSet the pixel format of
DXT1 encoded images to be RGB variant of DXT1
options: dds_dxt1_rgba Set the pixel format of
DXT1 encoded images to be RGBA variant of DXT1
options: dds_flipFlip the image about the
horizontl axis
}
}
To get the old automatic detection of DXT1 RGB vs RGBA you'll need to
use the "dds_dxt1_detect_rgba" option string.
I've gone for the default what I feel is probably most approrpiate,
but am aware I don't regularily use DXT1 compressed data coming in
from 3rd party sources in my work, so you own art parth routes may be
quite different. Please chip in.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DDS with DXT1 with and without alpha
Hi All,
I have now implemented the various options I suggested in my previous
post, and for now have opted to default to DXT1 RGB pixle format for
DXT1 files, unless the alpha bit in the dds header is set, then it
will choose DXT1 RGBA pixel format. The OSG's DDS plugin does set the
alpha bit when writting out DXT1 RGBA images, but other 3rd party
tools such as nvcompress do not, so for these 3rd party generated
images the dds plugin will now read all these DXT1 files as RGB.
These changes are now checked into svn/trunk.
You can list the new options using:
> osgconv --format dds
Which will output:
Plugin osgPlugins-2.9.12/osgdb_dds.so
{
ReaderWriter : DDS Image Reader/Writer
{
features : readObject readImage writeObject writeImage
extensions : .ddsDDS image format
options: dds_dxt1_detect_rgbaFor DXT1 encode images
set the pixel format according to presence of transparent pixels
options: dds_dxt1_rgbSet the pixel format of
DXT1 encoded images to be RGB variant of DXT1
options: dds_dxt1_rgba Set the pixel format of
DXT1 encoded images to be RGBA variant of DXT1
options: dds_flipFlip the image about the
horizontl axis
}
}
To get the old automatic detection of DXT1 RGB vs RGBA you'll need to
use the "dds_dxt1_detect_rgba" option string.
I've gone for the default what I feel is probably most approrpiate,
but am aware I don't regularily use DXT1 compressed data coming in
from 3rd party sources in my work, so you own art parth routes may be
quite different. Please chip in.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DDS with DXT1 with and without alpha
Hi All, I have been investigating issues with handling of .dds image files that contain DXT1 compressed RGB data, with some of these files being picked out as being RGBA because they have a black pixel within them. I've looked at what documentation on DXT1 I can find on the web and have what looks to be a conflict/ambiguity between Microsfts online docs on DXT1: http://msdn.microsoft.com/en-us/library/bb204843(v=VS.85).aspx http://msdn.microsoft.com/en-us/library/bb147243(v=VS.85).aspx And the GL spec for the S3TC compressed texture extension: http://www.opengl.org/registry/specs/EXT/texture_compression_dxt1.txt To me it looks like the MS docs refer to what is effectively the GL_COMPRESSED_RGBA_S3TC_DXT1_EXT pixel format, and there is no equivilant to the GL_COMPRESSED_RGB_S3TC_DXT1_EXT. On the GL side the only difference between the RGBA and RGB versions of DXT1 is that RGBA interprets a alpha of 0 while RGB interprets black for the same bit setting in the data format. Problems arise because the dds format doesn't explictly distinguish between the RGB and RGBA versions of DXT1 so you are left to guess which is intended. Frustratingly the dds format does have bits in the header for specifying alpha in the pixel format but the 3rd party generated dds files I have the alpha bit is only looks to be properly set when using uncompressed RGB vs RGBA. Our dds writer does actually set the alpha bit when writing out GL_COMPRESSED_RGBA_S3TC_DXT1_EXT so our dds reader has all the info it needs to reliably distinguish between the two, but alas.. it's the 3rd party data that most users will be dealing with. Up till now the dds plugin has been addressing the ambuguity by checking the presense of 0 alpha entries in the DXT1 pixel blocks, however, this check is invalid if black has been encoded as part of a GL_COMPRESSED_RGB_S3TC_DXT1_EXT compressed image. All these checks do is assume that the format is GL_COMPRESSED_RGBA_S3TC_DXT1_EXT and check for the presense of any 0 alpha entries, and if so set the format to GL_COMPRESSED_RGBA_S3TC_DXT1_EXT otherwise set it to GL_COMPRESSED_RGB_S3TC_DXT1_EXT. Given this checks are not robust, I don't think we should be relying upon them, particularily in the default implementation in plugin. >From what I can work out MS's docs describe the GL_COMPRESSED_RGBA_S3TC_DXT1_EXT format, so if one follows this onto the dds format perhaps one should just default to GL_COMPRESSED_RGBA_S3TC_DXT1_EXT. However, in general documentation on DXT that I've seen on the web suggests using DXT1 for RGB data and DXT3 or DXT5 for RGBA data, and only in special cases where 0 or 1 alpha is acceptable might you consided DXT1a (RGBA version of DXT1). Given this perhaps we should be assuming GL_COMPRESSED_RGB_S3TC_DXT1_EXT. Another complication has that some applications and other other OSG plugins use the pixel format information to tell whether a texture and stateset associated with them should be classified as transparent so should have blending and dropped into the transparent bin for depth sorting. There is an osg::Image::isImageTranslucent() method that helps this process, but it previously didn't handle the DXT formats at all. Yesterday I added support for DXT1 into the isImageTranslucent() method, and simplified the dds DXT1 RGBvsRGBA detection code to use this, this provides a little more general functionality as well as make the code in the dds DXT1 RGBvsRGBA detection code in the dds plugin clearer. However, the new DXT1 RGBvsRGBA detection code is no more robust than original code - it still wrongly tags DXT1 RGB with black pixels as being RGBA. There isn't any way to make this detection code robust - the ambiguity is built into the format, so it's not a case of just needing to fix a bug, but a case of deciding on what policy to take when dealing with this ambuiguity - hence this email, giving the community a chance to discuss the options and what the defaults should be going forward. The options I can see are: 1) Keep the current assumption of DXT1 RGBA encoding and use the DXT1 RGBvsRGBA detection code to switch back to RGB when no 0 alpha pixels are found. This does wrongly identify DXT1 RGB encoded images with black pixels as being RGBA. 2) Always assume DXT1 RGBA encoding for dds files. Let applications reset to RGB if they know the image to RGB encoded. 3) Always assume DXT1 RGB encoding for dds files. Let applications reset to RGBA if they know the image to RGBA encoded. 4) Use an osgDB::Option setting to set what on the above behaviour should be. Now Option 4 is what I'm actually about to implement... but... it doesn't resolve what the default setting should be, Option 1 would keep the status quo as it is, which will work OK for some apps, but fail for others. Options 2 and 3 won't be perfect for all apps either. So what are end users experiences with DXT1 RGB and RGBA encoded images? Do you use DXT1 for only RGB, only for RGBA, or both?
