Everytime I try, it creates a corrupted image.
For example, I cropped this image and saved as .dds. Xnview then added extra space below the image and created a mirror image to the right.
I mean, look at this : https://i.imgur.com/IjdSDRH.jpg
You can see the image got corrupted somehow. Have tried re-saving multiple times, it just keeps coming out exactly the same.
xnview classic 2.48 cannot save dds files properly
Moderators: XnTriq, helmut, xnview
-
- Posts: 11
- Joined: Sat Feb 13, 2016 9:34 am
-
- Author of XnView
- Posts: 44926
- Joined: Mon Oct 13, 2003 7:31 am
- Location: France
Re: xnview classic 2.48 cannot save dds files properly
could you send me the jpeg file that you convert (with wanted size)
Pierre.
-
- Posts: 11
- Joined: Sat Feb 13, 2016 9:34 am
Re: xnview classic 2.48 cannot save dds files properly
Just use any jpeg file and try converting to DDS. I have tested it with different files, they ALL get a graphic corruption when converting to DDS.
-
- Posts: 19
- Joined: Tue Mar 03, 2020 7:28 am
Re: xnview classic 2.48 cannot save dds files properly
The DDS export option needs to be improved.
1) It only allows power of 2 dimensions and the padding is not clean, as shown in the above example. If the input height is not mod4, some rows are discarded before the image is padded to pow2 height. A warning could be presented if the image does not meet the constraints for DDS.
2) Output image always has an alpha channel even if the file originally did not, and is therefore double in size.
3) There are no options for selecting compression and color format. DXT yields poor quality in general and is unsuitable for bright sprites of contrasting colors. It is also slow and unnecessary when an image needs to be output for preview repeatedly. Uncompressed 32-bit ARGB, 16-bit 565 (nice with bright colors and mips at ½ size), DXT1 (no alpha), DXT3 (4-bit alpha for shapes/fonts), DXT5 should be available.
4) No option for generating mipmaps. No option for loading mipmaps to check their quality deterioration.
5) Saved DDS usually have a green tint, which is probably caused by truncation during 565 color reduction (for DXT). I am not sure if this is correct or not. But other software manages to maintain colors closer, and add less generation loss for DXT.
1) It only allows power of 2 dimensions and the padding is not clean, as shown in the above example. If the input height is not mod4, some rows are discarded before the image is padded to pow2 height. A warning could be presented if the image does not meet the constraints for DDS.
2) Output image always has an alpha channel even if the file originally did not, and is therefore double in size.
3) There are no options for selecting compression and color format. DXT yields poor quality in general and is unsuitable for bright sprites of contrasting colors. It is also slow and unnecessary when an image needs to be output for preview repeatedly. Uncompressed 32-bit ARGB, 16-bit 565 (nice with bright colors and mips at ½ size), DXT1 (no alpha), DXT3 (4-bit alpha for shapes/fonts), DXT5 should be available.
4) No option for generating mipmaps. No option for loading mipmaps to check their quality deterioration.
5) Saved DDS usually have a green tint, which is probably caused by truncation during 565 color reduction (for DXT). I am not sure if this is correct or not. But other software manages to maintain colors closer, and add less generation loss for DXT.