Currently just throws an error. Change to wrote magenta block instead.

Hi! Any chance of a nuget release that depends on the latest SharpLabors.ImageSharp version (1.0.1) rather than 1.0.0-beta0007 ?

Hi,

I know I can be a bit dense, but it took me like 5 minutes to get the main page example working. I think it should include the "usings"

using BCnEncoder.ImageSharp; was specially hard, as for other usings you can right click and if you're lucky to have intellisense, it will help you, but with the BCnEncoder.ImageSharp one you have no idea what to search for... (I had to go check the tests to see what was different).

At least it works now, time for fun! :)

This issue arises from the fact that mip count is handled differently in DdsFile and in DecodeInternal.

These are the relevent lines:
https://github.com/Nominom/BCnEncoder.NET/blob/master/BCnEnc.Net/Decoder/BcDecoder.cs#L1161-L1164
https://github.com/Nominom/BCnEncoder.NET/blob/master/BCnEnc.Net/Shared/ImageFiles/DdsFile.cs#L57

I think the easiest way to fix this would to be assume that each file has at least 1 mipmap. Microsoft says that you shouldn't rely on the mipmap flag being set.

Seems like cubemap decoding is missing from the ImageSharp API. One user already implemented it themselves, but it would be nice to have in the official API.

As the title suggests, this project would be a pretty good addition to nuget.

DecodeRaw is currently a wrapper for DecodeRawInternal which itself accepts ReadOnlyMemory<byte>.
There is no reason why the public function shouldn't also accept ReadOnlyMemory/ReadOnlySpan.

Add support for ETC1S.

https://www.khronos.org/registry/DataFormat/specs/1.1/dataformat.1.1.html#ETC1

This project is mostly about block-compressed formats, so including the HdrImage-class was a band-aid fix to allow usage with any kind of a HDR-format. Ideally ImageSharp would implement HDRsupport or another Image library would have it, so I could make an extensions package for it.

Here is some dwFourCC's that might be found in a dds, but the DdsFile does not recognize them.

While encoding, always prefer the DX10 extended header by default. Also add an option for encoder to prefer dwFourCC over DX10 header for formats which can be written there (BC1 - BC5).

Add tests for encoding and decoding files with the dwFourCC preferred.

This currently doesn't break anything but Unsafe.SizeOf is the correct way to do it.

Colors are not interpolated correctly between the two endpoints compared to other decoders.

The colors are 1 or 2 255th off per channel because of floating point interpolation. This might be an issue.

I'm currently working on implementing ATC and I noticed how the Blocks are actually cast and read now. The current approach of casting the memory containing the blocks to the struct type only works out if the executing architecture is Little Endian.
The current code only works since all Block Compressions are specified as being stored in Little Endian, so a LE architecture has no trouble with the code.

Is it a concern that the library should work independant from the architecture of the executing system?

Current default for most of the code is Ycbcr or scaled rgb error metrics. The encoder should have an option to use raw rgb error metrics as well.

I have a BC3 image that I decoded with my own decoders. I'm not sure how the original BC3 image was created (maybe with nvidia texture tools?). Once I decoded the main mip from the image, I encoded it again to BC3 using your library. Then I decoded the newly encoded image again (with my own decoder), and I noticed that there are issues/differences in how the smaller mip levels look.

I have attached the original images in the expected folder, and the new images using your encoder in the actual folder. I used the following code to encode the images:

BcEncoder encoder = new BcEncoder();
encoder.OutputOptions.generateMipMaps = true;
encoder.OutputOptions.quality = CompressionQuality.BestQuality;
encoder.OutputOptions.fileFormat = OutputFileFormat.Dds;
encoder.OutputOptions.format = CompressionFormat.BC3;
encoder.OutputOptions.ddsBc1WriteAlphaFlag = false;
encoder.OutputOptions.maxMipMapLevel = 5;

Image<Rgba32> faceImage = ...;
var encodedData = encoder.EncodeToRawBytes(faceImage);

mipmap.zip

It seems the dds file loader assumes that pitch is always stored in place of the header field pitchOrLinearSize. This fails when linear size is stored since the computation essentially becomes width * height * height which can result in a number larger than int.Max that arrays support.

https://github.com/Nominom/BCnEncoder.NET/blob/master/BCnEnc.Net/Shared/DdsFile.cs#L80

I am not super sure on this one so please just correct me if I am wrong: every resource I read pointed towards Bc2/3 being exactly the same, the difference only being that Bc2 colors are premultiplied with alpha.

However in the current implementation Bc3Block uses Bc4ComponentBlock which produces very much different results.

Currently the high performance dependency uses a preview release. The package now has a stable version. Would be great to get a new nuget package with the latest stable version.

This should be optional and off by default.

Premultiplied alpha increases the perceived quality when resizing partly transparent images, but will mess things up if alpha channel is used for something else.

http://richg42.blogspot.com/2021/02/rdo-bc1-bc7-progress.html?m=1

http://richg42.blogspot.com/2021/02/tricks-to-help-reduce-bc7s-output.html?m=1

http://richg42.blogspot.com/2021/02/the-two-types-of-rdo-bc7-encoders.html?m=1

B = sqrt(1 - (sqrt(R) + sqrt(G)))

I'm converting a decoded BC6h uf16 RgbFloat to Bgr24. Assuming I haven't made a mistake, it appears there may be corruption in the decoder.

Nuget: BcnEncoder.NET ImageSharp 1.1.1
Sample.zip

Here's my code:

var fileName = @"";
var outFileName = fileName + ".png";
var bcDds = DdsFile.Load(fileName);
var width = (int)bcDds.header.dwWidth;
var height = (int)bcDds.header.dwHeight;

var decoder = new BcDecoder();
var source = decoder.DecodeHdr2D(bcDds);

var pixels = new byte[width * height * 3];
var pixelsSpan = MemoryMarshal.Cast<byte, Bgr24>(pixels);
for (var r = 0; r < height; ++r)
{
    var destRow = pixelsSpan.Slice(r * width, width);
    var sorcRow = source.Span.GetRowSpan(r);
    for (var c = 0; c < destRow.Length; ++c)
    {
        ref var destPixel = ref destRow[c];
        ref var sorcPixel = ref sorcRow[c];

        var rgbVal = sorcPixel.ToVector3() * byte.MaxValue;
        var bgr24 = new Bgr24(
            Math.Clamp((byte)rgbVal.X, (byte)0, byte.MaxValue), 
            Math.Clamp((byte)rgbVal.Y, (byte)0, byte.MaxValue), 
            Math.Clamp((byte)rgbVal.Z, (byte)0, byte.MaxValue));
        destPixel = bgr24;
    }
}

unsafe
{
    fixed (void* wrap = pixelsSpan)
    {
        Image.WrapMemory<Bgr24>(wrap, width, height).Save(outFileName);
    }
}

If the image dimensions are not a multiple of 4, the last edge blocks should be padded. This already happens in normal encode methods, but not in single-block encode.

There's a lot of code-duplication on the public and internal API's. This can probably be reduced by quite a lot.

Hi, I've been working on a program that can create .YTD files from folders using images for Grand Theft Auto V.
Due to the game's nature, I need to convert the numerous image files to .DDS so I'm using BCnEncoder.NET for that, but I'm having serious issues with some images, one of my testers has some textures that was extracted from Assetto Corsa and some of those textures can't be encoded, I'm getting the following error:

I already tried resaving the image (maintaining the same format) using Photoshop and Paint.NET and I even save it as .TGA

From a folder that has 34 textures just 30 of them were successfully converted to .DDS.
So I will attach those four textures as well: crash.zip

And this is the code I'm using to export the .DDS

var amigo = bcEncoder.EncodeToDds(image); //Here's where the crash happens

MemoryStream ms = new();

amigo.Write(ms);

byte[] ddsbytes = ms.ToArray();


File.WriteAllBytes(Path.GetDirectoryName(filename) + "/" + GetImageName + ".dds", ddsbytes);
LbProgressLog.Dispatcher.Invoke(() => { LbProgressLog.AppendText($"\nDDS conversion of {Path.GetFileName(GetImageName)} was sucessful..."); });

Program details:

• .NET 6
• WPF
• Targeted for Windows7+

Add tests for Bgra encode / decode for both dds and ktx (if ktx supports bgra).

As discussed in issue #15 an async api would benefit consuming programs of this library to design non-blocking UI's while decoding and encoding processes are running.
Currently all classes seem to be thread-safe already, so it would just suffice to offer Async methods that wrap starting the async operation. This needs further investigation though.

It seems the code allocates all blocks necessary during decoding, but these blocks are only used temporarily. It would be ideal if instead of allocating separate blocks, the decoded data is written directly to the output instead of these temporary blocks.

An example could be that the blocks to process are divided up so that they are separated evenly on each thread. Each thread allocates a single RawBlock4X4Rgba32 and decodes each block serially using that temporary block. Then the contents of the raw block are written directly to the output image at the proper location.

Not sure if this is worth it, but interested to hear your thoughts.

When using Bc1a format, any alpha below the cutoff will be treated as transparent.

Would it be a desirable feature to add report progress for encoding and decoding processes? For longer running processes like best quality compression, this might be helpful if the library is used for GUI's.

There already are build-in types in .NET like IProgress<T>. And maybe the progress reporter can be part of the decoder/encoder options.

Any chance you could add a build configuration for .NET Framework (preferably 4.5)?

Most users don't use ktx or dds capabilities at all, but instead use the raw-methods to do their encoding and decoding. By separating ktx and dds to an extension package, the default use-case becomes using the raw methods.

The extension package could also include support for new texture formats, like VTF.

The HighPerformance library was renamed from Microsoft.Toolkit.HighPerformance to CommunityToolkit.HighPerformance at some point recently, and the change results in binary incompatibility which makes working with this library occasionally difficult for projects that already use the new named package.

Hi,

I currently use Unity which only supports .NET Standard 2.0 Dlls, is making the library compatible with .NET Standard 2.0 on the plans?

Thank you!

ATC is a rather exotic derivation of DXT, but it exists. I first encountered it on my work for Dai Gyakuten Saiban Mobile. Depending on the phone, the engine chose a certain image from the internal image format. And those image formats contained an encoding similar to DXT, but with slight variations.

ATC is supported in hardware by Adreno mobile GPU's (and that's where probably the name comes from, Adreno Texture Compression) and as said above, is a derivation of DXT. Here's a document detailing the differences between ATC and DXT, and how to easily convert DXT to ATC and vice versa.
http://www.guildsoftware.com/papers/2012.Converting.DXTC.to.ATC.pdf

I think it would be a nice addition, even though ATC is not that widespread.
(I already have a working implementation of ATC, so I can probably provide that one within the next week)

Encode a few blocks with same endpoint colors (and indices?) to make them more compressible with lzma/deflate and such.

After PR #14 the issue #3 is now fixed in Bc1, 2 and 3. Bc4, Bc5 and the alpha block in Bc3 still seem to have some issues.

Currently investigating what's up.

As briefly discussed in #27 and #9, removing imagesharp as a dependency is under consideration. This would require manual implememtation of a resizing algorithm. The main package api would be changed to use raw bytes or generics argument type. When supplied with a generic argument, the type would be blindly casted to an internal Rgba32 format. Here we cannot guarantee that the input data is in the right format. We could also implement Span2D support.

Current ImageSharp api could be extracted to an extension package, that would add the current ImageSharp.Image based api.This would mainly be for convenience. We could also add an extension package for different image libraries, so the user is not locked to a single one.

What are your thoughts on such a change? Would it be more beneficial or harmful overall?

The benefits in my view are:

• Not locked in to a single Image library
• User has a choice to not use any external image library
• We can add support for older .net versions

What do people think about adding a BcStream class? It would be a Stream-based implementation of BcEncoder/BcDecoder, that would only convert raw data between different formats (no file headers, no mipmaps). Like from Rgba to compressed Bc1. This popped up in discussion in issue #9. Feedback is wanted: how would this be best implemented and would this be useful?

Add support for UASTC:

https://github.com/BinomialLLC/basis_universal/wiki/UASTC-Texture-Specification