Releases: nickbabcock/Pfim
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
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