0.11.2 - January 11th 2023

• Implement RGB swap for BGR8 DDS images

0.11.1 - August 17th 2022

• Fix targa and dds decoding from publicly visible memory streams

0.11.0 - August 16th 2022

Breaking Changes

The Pfim class has been renamed to Pfimage to avoid namespace collision. Migration should be simple:

- using (var image = Pfim.FromFile(file))
+ using (var image = Pfimage.FromFile(file))

Other Changes

• Fix rounding errors in DXT1, DXT3, and DXT5 where the decoded channels may be inaccurate within a few degrees. See PR #98 and issue #88 for more info
• Fix image decoding on smaller buffers and chunked streams
• Pfim is now a strong named assembly
• Code samples updated to use NET 6.0

0.10.3 - January 1st 2022

• Add support for B5G5R5A1_UNORM encoded DDS images

0.10.2 - December 14th 2021

• Add initial support for b8g8r8x8 encoded DDS images

0.10.1 - July 8th 2021

• Add more support for TGA images with dimensions that require stride padding

0.10.0 - February 8th 2021

• Add support for decoding DXT1 with alpha channel. This required changing the
  image format of DXT1 images to 32 bit rgba instead of 24 bit rgb, so this is
  technically is a breaking change as code that assumed 24 bit data for DXT1
  images will need to change.
• Add a floor of 1 to dimensions of mipmap calculations

0.9.1 - November 20th 2019

Much thanks to @ptasev for this release:

• Add BC4 DDS support
• Add BC5S DDS support
• Add BC6H DDS support

0.9.0 - November 12th 2019

Much thanks to @ptasev for identifying the bugs / implementing features

• Support for BC7 DDS decoding
• Support for BC2 DDS decoding
• Support for BC5U DDS decoding
• Fixed decoding of BC3 and BC5 DDS
• Fixed blue channel for BC5 DDS images when allocator reused buffer

0.8.0 - September 5th 2019

Two big changes: netstandard 2.0 targeting and DDS mipmap support.

With a bump to netstandard 2.0, Pfim is able to slim down dependencies and the amount of code that is conditionally compiled. The only platforms that lose out here are platforms that are EOL or nearing EOL.

Each image file may contain several images in addition to the main image decoded. There are pre-calculated / optimized for smaller dimensions -- often called mipmaps. Previously there was no way to access these images until now.

New property under IImage

MipMapOffset[] MipMaps { get; }

With MipMapOffset defined with properties:

public int Stride { get; }
public int Width { get; }
public int Height { get; }
public int DataOffset { get; }
public int DataLen { get; }

These should look familiar to known IImage properties, the one exception being DataOffset. This is the offset that the mipmap data starts in IImage.Data. To see usage, here is a snippet for WPF to split an IImage into separate images by mipmaps

private IEnumerable<BitmapSource> WpfImage(IImage image)
{
    var pinnedArray = GCHandle.Alloc(image.Data, GCHandleType.Pinned);
    var addr = pinnedArray.AddrOfPinnedObject();
    var bsource = BitmapSource.Create(image.Width, image.Height, 96.0, 96.0, 
        PixelFormat(image), null, addr, image.DataLen, image.Stride);

    handles.Add(pinnedArray);
    yield return bsource;

    foreach (var mip in image.MipMaps)
    {
        var mipAddr = addr + mip.DataOffset;
        var mipSource = BitmapSource.Create(mip.Width, mip.Height, 96.0, 96.0,
            PixelFormat(image), null, mipAddr, mip.DataLen, mip.Stride);
        yield return mipSource;
    }
}

Example image:

Only additional images are stored in MipMaps (the base image is excluded).

This continues the work in 0.7.0 were users should start relying on the DataLen property and not Data.Length as now multiple images share this buffer