Paint.Net DDS2 naming files .dds2 - Plus no Linear fine option

[m0lz]

Couple of issues found ...

1. When saving one of the new format DDS .. Say BC7

The file is given a filename like name.dds2

Which is sort of ok, if you rename it to .dds then the target game will recognise it for the type of dds it is anyway - Would just be better if we did not have to rename it and it used the .dds extension as normal.

Note Intel Texture Works plugin for Adobe Photoshop does not have this problem, a BC7 dds file with the normal .dds file extension loads just fine into Adobe Photoshop, just like they do with a game engine that supports them (Skyrim Special Edition / Fallout 4).

Also, when loading the same texture back into Paint.Net, if the file is now named .dds, PDN will try to load it but fails to recognise the file, even though it was made with PDN - Solution = rename it name.dds2

Then PDN will recognise and load it correctly O_o, bizarre state of affairs.

Can you fix this behaviour please.

---

2. In accordance with Intel Texture Works plugin save dialogue we are supposed to be able to save a BC7 as Linear Fine (second BC7 option in the linked screenshot)

But in the save dialogue for dds2 implemented in PDN there is no such option that seems to stick to the same naming convention

Which of your options equates to ..

BC7 8bpp Fine (Linear, DX11+)

And if you do actually support the same option, could it be made to read as BC7 Fine Linear in accordance with the Intel Texture Works dialogue screenshot, so that we are all singing off the same hymn sheet and know for certain the format saved is the format desired.

[m0lz]

The second issue of conforming to the same naming conventions as per the Intel Texture Works plugin for Adobe Photoshop is so that when we select a format it is the same name. Choosing from your options in the PDN plugin at the moment does not fill me with confidence that I am saving in ..

BC7 8bpp Fine (Linear, DX11+)

.. and will end up with a normal map that has barely detectable compression artifacts (which is desired, and would not be true if I get the option chosen wrong due to different naming conventions)

Compare this screenshot

With this screenshot

BC7 Linear Fine (the latter screenshot) has very little compression artifacting which can show up very much on an in game model where the artifacting is translated into bump mapping on the surface of a model, depending upon your 3D point of view on the object, such compression artifacting can look awful in game .. So getting the right format to save and sticking to the naming conventions is quite important here.

[0xC0000054]

I can add Linear to the description of the non-sRGB formats, but I will not be changing the rest of the description to match the Intel plug-in.

This plugin and the Intel plugin use different methods when compressing the BC1, BC3, BC5 and BC7 formats. So it would not make sense to copy the 'Fast' and 'Fine' naming convention used by the Intel plug-in.

The Intel plug-in uses the ISPC Texture compressor (it provides the 'Fast' and 'Fine' modes), and this plugin uses DirectXTex.

Does this plugin show any compression artifacts when saving as BC7 (DX11+)?

[m0lz]

Thank you for considering adding Linear.

Yes I have tried saving out a normal map (4096x4096) in BC7 (DX11+), in Quick, Normal and Max, then loaded up all 4 again (original plus the three generated)

All 4 textures were exactly the same size on disk, 5.33mb - So there is no difference there.

Visually there are very slight differences if you zoom in to certain places .. All three modes introduce a very small amount of artifacting at great magnification (zoom in x 8 in PDN), all in the same places but with slight differences in which pixels were affected. There is very little difference between the three modes, none are worse than another, they introduce a similar amount of difference to the original ..

So it is very hard to tell which is best. They all do a tiny bit of artifacting which is hard to see unless zoomed in, but none are visually worse than another.

Would Max be the equivalent of Fine, or is Max more compression = Less quality, and so choosing one of the other options would give better results in the final saved texture ? But if that is true .. Then they would all differ in file size, which is not the case.

So if Max is the equivalent of Fine, then visually why is there not so much difference (as you would see when choosing between Fast or Fine in the Intel Texture Works plugin).

I just dont understand how to use this to best advantage when there is visually very little difference between the resulting normals, and no difference in file size which may mean one is better for optimal loading if there was .. But there isn't.

[m0lz]

Here is another screenshot, using the Intel Texture Works test image, and then cut out two of the squares to zoom in to, cropped those and enlarged the whole image.

Then saved out a copy using BC7 (DX11+) Quick, then Normal, then Max.

Then side by side compiled all four images into one result ..

Screenshot

Quick was the only mode to show any kind of difference with the whole image upscaled twice. Normal and Max are just about identical to the original.

And all three generated images (when separate), were the same file size.

So I would say Max is probably best for resulting image quality - Which kind of doesnt sound right when you read (as a user of the plugin) Compression Mode = Max sounds like it would give less quality, or smaller file size, both of which are not proving true.

From your perspective as programmer it probably makes perfect sense from your understanding of how it works, but to users we are choosing what sounds like will be a worse option to get the best, with no actually better compression. To me DirectXTex method and terminology of the dialogue is confusing.

Or is the PDN plugin not doing exactly what it is supposed to be doing, so it would make better sense if it was ?

[0xC0000054]

To me DirectXTex method and terminology of the dialogue is confusing.

I agree. DirectXTex is a library that appears to have been written for graphics or game engine programmers who would know what all the advanced options are and when they would need to be used.

Would Max be the equivalent of Fine, or is Max more compression = Less quality, and so choosing one of the other options would give better results in the final saved texture ?

The quick and max option names were taken from the corresponding parameters in the DirextXTex Texconv utility, which documents them as follows.

-bcmax Uses maximum compression (BC7: enables mode 0 & 2 usage) -bcquick Uses minimal compression (BC7: uses just mode 6)

After reading the DirectXTex source code it became clear that those options control how many of the BC7 Modes DirectXTex will try when picking the best mode to compress each 4x4 pixel block.

I will probably change the BC7 compression mode dialog options to use Fast, Normal and Slow as this better reflects that it controls how many of the BC7 modes DirectXTex will try to use when compressing the image data.

So if Max is the equivalent of Fine, then visually why is there not so much difference (as you would see when choosing between Fast or Fine in the Intel Texture Works plugin).

After looking through the ISPC Texture compressor and DirectXTex source code it appears that the Intel Texture Works plugin 'Fast' setting skips modes 0, 1, 2 and 3 and the DirectXTex 'Normal' setting will skip modes 0 and 2.

The Intel Texture Works plugin 'Fine' setting skips mode 2 and the DirectXTex 'Max' setting will use mode 2.

I do not know what effect the different modes would have on image quality.

[m0lz]

Sounds like Max = Fine ( with a slightly amended ( possibly better ) approach than Fine ) = For best image / texture quality you can get from choosing BC7 Linear (DX11+)

With your amended mode naming Slow ( = Fine ), makes better sense from a user perspective because it has to work harder / longer (slow) at getting the best results.

Sounds good to me :)

[0xC0000054]

Released version 1.7.1 which adds 'Linear' to the non-sRGB format descriptions and renames the BC7 Compression Mode Quick and Max values to Fast and Slow.

Closing this issue.