FS2004 How to see in a dxt3 file if a alpha channel is present? (C#)

[garfield_x]

Hi

I want to be able with a C# program to see if a DXT3 file has an alpha channel present or not.
DXT3 is quiet new for me.
Is there an easy way for it? (looking for a bit set or not)
Googled a lot, found a lot about DXT3 but not what i could use.

I just want to make a small program that scans the scenery folders and find all the DXT3 files that has no alpha channel.
(or maybe if such a program exist just tell me )

 

[VOSt]

i think if you open it with a free program like dxtbmp you will be able to se the content of the alpha channel

but the problem is that every dxt3 has the alpha. the alpha-less dxt3 has also alpha information, but it is set to the whole alpha information bit-map as white color.

 

[garfield_x]

Of course i know that, but as said that's not what i want.

Also imagetool gives that information.

I want to be able to programmatically see if its present or not so i can produce a list of DXT3 scenery textures that needs alpha channels.

 

[n4gix]

But, that was entirely the point...

By design and definition all DXT3 files have a 4bit Alpha channel!

There is no such thing as a DXT3 file without an Alpha channel...

Only the DXT1 compression format allows for the option of a 1bit Alpha channel or not.

 

[arno]

Hi,

As said, every DXT3 texture has an alpha channel.

There is no single bit to see if the texture has one or not. The data is stored per block of 4x4 pixels. You would have to check all these blocks in the texture to see what values the alpha channels have.

 

[garfield_x]

Ok.

I understand that i have to decompress the image and see what the values are.

But if i open some DXT3 files with imagetool is says to me that there is no alpha channel present.
If i open that file in dxtbmp and save it again then recheck it in imagetool the alpha channel is preset (added by just opening and saving the bmp in dxtbmp)

I was asking this because of the finding that lots of commercial scenery have dxt files without an alpha channel present (according to imagetool). This result in a stutter/loss in FPS when viewing these textures (because the graphics card creates one on the fly then)

See the following links about this..

http://www.alpha-india.net/forums/index.php?topic=3984.msg81769#msg81769

http://www.alpha-india.net/forums/index.php?topic=8581.0

Now people open the bmp files in imagetool to check if alpha is present or not then open and save the file in DXTBMP all by hand.

My thought was if there was an easy way to determine if an alpha is present or not it could be a huge time saver.

 

[rhumbaflappy]

It would be nice if you actually attached a zipped file of these "alpha-less" dxt3 textures.. so we would have some glimmer of what you are describing.

Giving us links to a forum that requires registration does no one any good.

This is a common problem here... people ask for help in an impossibly incomplete manner. You need to give us all the info... or else settle for the previous answers already given, based on incomplete info.

Dick

 

[arno]

Hi,

As dick says, can you show a file with and without the alpha channel? I can take a look using my dxt reader to see what the difference is.

 

[garfield_x]

It would be nice if you actually attached a zipped file of these "alpha-less" dxt3 textures.. so we would have some glimmer of what you are describing.

Giving us links to a forum that requires registration does no one any good.

This is a common problem here... people ask for help in an impossibly incomplete manner. You need to give us all the info... or else settle for the previous answers already given, based on incomplete info.

Dick

Thank you for your polite answer.
It is of much help. Esp. the last paragraph.

I had thought that FS people here also visit the AIG forums, but it seems not.
Despite that, most forums needs registration.

One of the links describes a list of sceneries/files which has those problems (I will not quote as it is a long list), the other which describes a bit the problem i will quote here.

My standard operation now after installing any scenery is this:

1: Open Imagetool and open every texture about 15 at a time. On the info box on the right it will tell you the format of each texture and its Alpha status.
What you want to see is "Alpha: Alpha"
If you see "Alpha: None" Then you have a bad texture.

I always convert 32-bit to DXT3, but thats personal preference.

2: Any DXT3 textures that do not have an alpha (Remember DXT1 is OK without an alpha, so don't worry about them) I open in DXTBMP. All you have to do is just hit save and DXTBMP adds an alpha to the texture automatically (What an awesome program that really is).

I add mips to day textures to reduce shimmering - again personal preference and if you dont have your graphics card/nhancer settings set up correctly you will get blurries, so proceed carefully. I have a gorgeous looking FS9 with 8xS AA and absolutely no shimmering at all, its so smooth its ridiculous Cheesy

I am afraid I can't list the KORD textures that are affected as I have already converted them all and can't remember which ones were missing the Alpha.

The pain with missing alpha's is that the file size is the same whether the alpha is present or not so there is no way of telling without actually opening each texture in Imagetool.
If anyone wants to do an experiment to see the impact of missing Alpha's on DXT3 textures try the following (Its a bit of work but its a clear demonstration of the issue).
Go to an airport that runs smooth, for example FlyTampa KSEA. Take an airline that has a lot of traffic there say Alaska Airlines at KSEA.
Open a few AI aircraft textures in Imagetool and save as DXT1 - this will remove the Alpha. Resave as DXT3 it should show DXT3 now and Alpha: None.
For example with Alaska try the 737-700, 800 and 900. This will give you a fair few aircraft missing alpha's.
Now fire up FS and go check out the airport. Things will be smooth until your Alaska AI comes into view then you should get a horrible jerky stuttering mess.
This is because your graphics card is trying to add the alpha itself because a DXT3 texture must have an alpha channel and the card gets bogged down.
Remember to resave those textures as DXT3 in DXTBMP to replace the alpha, and you should be back to a nice smooth experience again.

It just amazes me how payware authors release products that are in essence defective. I have had to replace Alpha's in releases from almost every payware company (Flytampa being a notable exception - They also mip their textures which is why they don't shimmer). With only a few textures the stuttering will not be so noticeable maybe just an occassional hitch here and there when the involved textures come into view but with some where there are lots of alpha-less DXT3's the scenery is going to perform horribly.

Unfortunately Matthew I have not really studied FSX texture formats. My understanding is that DXT1 is fine with either an alpha or without. Beyond that, DXT3, DXT5 etc then an alpha must be included, even if its all white or black.
I would have to do further research on the .DDS format, so I can't really help on that at this time I am afraid.

Oh and Matthew I remember KLAS had a few problem DXT3 textures (from the main install - not sure on the resized package) - The KLAS_ED and roof textures I recall being big offenders as well as a few others. I think the ground textures were OK, maybe 1 or 2 missing ones.

Attached a zip with a bmp that according to imagetool has no alpha channel.

The post was already answered. there is no 'easy' way to determine if an image has an alpha channel or not so ....

 

[garfield_x]

to be complete also the same file opened and saved in dxtbmp (which add the alpha channel information)

 

[VOSt]

I've been using this method on every aircraft for VC textures, but i'm noticing some problems.

eg...
one image in dxt3 format with blank Aplha at 1024x1024 holds 1MB of space.
i convert it in dxt1 (without Aplha) and get 600kb, wich is more-less 60% of prev size.

Now i go to the VC and notice a huge incerease in FPS, and that is true. But, flying more then 20minutes gives me a drop in FPS under the one before converting. And before converting i was able to fly infitely without this problem.

So i think maybe the DXT1 or DXT2 is problematic because provides a memory leak...

So my simptoms are:
initilaly good FPS, but after while getting stutters and decreased FPS.
returning to 2D panel and staying within for the cruise part of the flight seems to clean the memory, so i go to VC only for descent, but usual i get problem again near airport because "tempus fugit".

And then i think to myself... "Ceterum censeo Cartagianem esse delendam"
so i return everything to DXT3

 

[garfield_x]

I think to myself ... what has this todo with my question?

 

[rhumbaflappy]

Hi Peter.

Oddly, a good program to see the DXT3 error is... imagetool.

When it tells you Alpha: None, it's also telling you something is wrong with the DXT3 texture. As discussed in both forums, the Alpha channel is required for DXT3... which is why the sim isn't dealing with it well. Something is not conforming with what the sim expects for a DXT3 alpha channel.

It appears the DXTBMP program is reading the alpha as a pure white. Martin may have programmed this in as a default ( bypassing the problem of having an alpha channel as a solid black... totally transparent ).

If you take the above DXTBMP example ( SIW_PKW2-01_LM2.bmp ) and load into imagetool, you see the alpha as solid white. You can then invert the alpha in Imagetool ( to solid black... totally transparent), and save as SIW_PKW2-01_LM3.bmp.

Reloading SIW_PKW2-01_LM3.bmp to Imagetool, then shows Alpha: None. I would assume this also would produce the problems you have in the sim with these types of textures.

It appears that Imagetool and the sim both have trouble with a solid black alpha... so Imagetool works well as a problem identifier for you. Oddly, DXTBMP can save an Alpha as solid black, and it will show properly in Imagetool... but reloading it to DXTBMP, it shows as white... not black. Again, that seems to be Martin's way of dealing with total tranparency.


I think the problem is this:

DXT3 requires an alpha channel. But a solid white or black channel is dumb.

Solid black would translate as invisible. Solid white would translate as opaque. If invisible, why show the object at all? If opaque, why use DXT3 ( use DXT1 - no alpha ).

These "alpha-less" textures seem to be using solid transparent ( black ) as the alpha. But looking with a hex editor, they are solid white... so maybe Martin's program is right and the sim & Imagetool is wrong. But as long as the sim and Imagetool agree, there is a consistancy for us.

I've played with this problem recently ( making a transparent FSX photoreal texture for resample), and the solution is to have 1 pixel in the alpha as not solid black. I make it a mid-gray which should be fine for DXT3. You can hardly see the pixel, but it satisfies the requirement for DXT alpha as not being totally transparent.

I understand your problem is that you would like to identify these problem textures in a large number of folders, so you can re-process them. I'll look at the textures with a hex editor, and see if there is a commonality we can find.

Dick

 

[VOSt]

I'm talking about a quote you have posted, so must think better.
but i was not talking about your first question... sorry just tried to help somehow

 

[rhumbaflappy]

Some progress.

There is a byte in the DXT3 file that seems to control whether the Alpha is recognized. Byte 3F hex may need to be set to 04.

If you take an image and format it to DXT3, create mipmaps, and save it with Imagetool ( with no alpha channel ) this byte is set as 01. And reloading this DXT3 in Imagetool shows as Alpha: None.

Setting that byte to 04 in a hex editor, and saving a copy of the file, now loads into Imagetool and shows Alpha: Alpha

I also took the file SIW_PKW2-01_LM2.bmp that was attached above and in Imagetool it shows Alpha: Alpha. Altering the 3F hex byte to 01, results in Imagetool displaying Alpha: None.

This may be enough to solve the problem in FS. If true, you could write a program to make sure all DXT3 textures have the byte set to 04. I would test this only on copies of your files!

Some files:

alphaless.zip

Of course, all this brings us back to the original problem. There is a DXT3 without alpha. It's there, but the 01 byte set prevents it from being displayed. I made a Smiley face with a proper alpha, mipped and saved as DXT3 from Imagetool, and it's OK, and the Alpha can display in Imagetool. Same file with the 3F byte set to 01 ( instead of 04 ), and it shows Alpha : None, and won't display in Imagetool.

Why are developers using DXT3 with no alpha channel? Why not use DXT1 with no alpha? You don't need an Alpha channel if you're not going to use it. And FSX, as well as FS9, are a bit sensitive to unacceptable textures. ( Also, why does Imagetool even allow a no Alpha channel DXT3 to be saved ? )

Dick

 

[rhumbaflappy]

A short note.

This applies to DXT3 of type bitmap ( .bmp ).

All bets are off for DXT3 saved as DDS ( .dds ).

The byte saved as 01 is None, 02 is ColorKey, and anything else seems to be Alpha. And this is true of DXT1 and DXT5 as well.

But, all bets are of when saved as DDS.

Dick

 

[arno]

Hi,

This is interesting. In my DXT/DDS reader I do nothing with that bit that differs. So even if the bit indicates there is no alpha channel in the texture, there is one defined that is all white. The DXT3 format always has an alpha channel defined.

So it seems that one bit is confusing FS.

Maybe a stupid question, but if there is no alpha channel in the texture, why not save it as a DXT1? It takes less disk space and there is no difference for the visual quality.

 

[rhumbaflappy]

Maybe a stupid question, but if there is no alpha channel in the texture, why not save it as a DXT1? It takes less disk space and there is no difference for the visual quality.

Hi Arno.

I was also stumbled by this... but I believe this is for FS2004 Aircraft, and by the SDK the _T textures need to be DXT3, with the alpha channel as the reflection map?

If it is not an aircraft _T texture, then DXT3 is a bad choice.

If I'm right, DXT1, DXT3, and DXT5 ( saved as BMP ) all have the alpha channel, but the byte can deactivate it... or define it as Color Key or just Alpha.

Dick

 

[arno]

Hi Dick,

Yes. The bytes are stored just outside of the normal BMP header. According to v5 of the BMP header the channel masks are stored here, but they are only valid for compression type bitfields. So it seems like this is something specific to the FS DXT BMP files.

 

[rhumbaflappy]

Hi Arno.

I wouldn't be surprised if this was just for FS. The industry standard is DDS, not BMP. I don't know if anyone else besides Flight Simulator uses BMP for DXTx images.

Dick