Announcing ImageSharp 4.0.0

ImageSharp 4 - .NET 8+, SIMD updates, decode-time color conversion, expanded metadata, new formats, and faster hot paths.

ReleasesImageSharp

ImageSharp 4.0.0 is out.

ImageSharp 4.0.0 includes a .NET 8+ baseline, SIMD and hot-path performance work, decode-time color conversion, expanded metadata and inspection APIs, new format capabilities, and correctness fixes across the formats people use in production every day.

ImageSharp is the foundation of the Six Labors suite, the only graphics stack in any ecosystem designed top to bottom, by one team, in pure .NET.

V4 is also the first ImageSharp release to enforce a build-time license key for direct package dependencies. More on that below.

What's new since V3 #

The main changes since V3 are:

  • A .NET 8+ baseline that lets ImageSharp use current runtime APIs directly.
  • SIMD work across pixel operations, JPEG conversion, compositing, and generated blender paths, including new Vector512 support.
  • Faster hot paths in resize, Porter-Duff compositing, image drawing, streaming, encoder internals, and memory access APIs.
  • Color management updates, with ICC conversion during decode, CICP metadata support, and explicit control over whether embedded profiles are preserved or converted.
  • Inspection, planning, and advanced integration APIs, including ImageInfo.GetPixelMemorySize(), MemoryAllocatorOptions.AccumulativeAllocationLimitMegabytes, IImageFrameVisitor, buffer subregion helpers, and expanded encoded pixel metadata.
  • Metadata conversion between formats, including shared frame timing, disposal, blending, color table, and encoded pixel information.
  • New user-facing capabilities such as APNG support, animated WebP encoding, OpenEXR read/write support, PXR24-compressed OpenEXR decoding, progressive JPEG encoding, JPEG comment marker support, built-in ICO/CUR support, transform additions, exposed convolution APIs, and continued animation improvements.
  • Decoder and metadata hardening across PNG, WebP, GIF, TIFF, JPEG, BMP, TGA, including configurable segment integrity handling for malformed ancillary metadata.

If you use ImageSharp in services, upload pipelines, media backends, rendering workflows, or any other production imaging system, V4 changes the parts of the library that usually determine throughput, memory use, format compatibility, and failure behavior.

.NET 8+ and SIMD work #

V4 is the first ImageSharp release built for .NET 8+. That removes older target-framework compatibility code and lets the library use the vector, memory, and JIT behavior available in current .NET runtimes.

V4 adds Vector512 support to the library's SIMD infrastructure, continues modernizing Vector128 and Vector256 code paths, and updates the low-level helpers used by pixel operations, JPEG converters, and generated blender implementations.

This work is not limited to CPU-family-specific code paths. V4 moves more code onto the newer cross-platform vector APIs so the library can use SIMD across modern .NET runtimes and hardware. That includes ARM-related work in WebP utilities, correctness fixes for non-SSSE3 paths, and SIMD cleanup outside a single codec or processor family.

The result is that more per-pixel conversion, blending, and codec work can use the same modern vector APIs across x64 and ARM paths.

Faster hot paths from resize to compositing #

V4 changes several hot paths: resize loops, compositing, pixel blenders, streaming, and encoder internals.

Resize convolution has been optimized. The Porter-Duff implementation now uses newer operators. The pixel blender APIs support single-color bulk operations, and the blending pipeline uses working buffers for compositing-heavy operations. ImageSharp.Drawing uses the same underlying blending pipeline for layered composition and generated graphics.

If you rely on DrawImage, overlays, watermarks, chart rendering, template-driven asset generation, or any workflow that repeatedly composites one buffer onto another, those operations now hit faster blending and compositing primitives.

Some other performance-facing highlights in this release:

  • Faster JPEG color conversion across RGB, grayscale, CMYK, and YCCK paths, backed by newer SIMD implementations.
  • Faster JPEG decode-and-scale paths, with specialized scaling routines for common factors and cleaner block normalization that improves both throughput and visual output.
  • A rewritten ChunkedMemoryStream for ImageSharp's non-seekable load and save paths. It buffers working data for network, upload, and pipeline scenarios without repeatedly reallocating and copying one growing contiguous array.
  • Reduced allocations in the lossless WebP encoder, which lowers GC pressure during repeated encodes.
  • A new adaptive HexadecatreeQuantizer, replacing the old octree quantizer with a 16-way palette builder, alongside simplified color-matching caches and cleaner palette lookup behavior for indexed workflows.
  • Row-stride overloads for memory APIs, allowing padded foreign buffers to be loaded or wrapped without repacking them first.
  • Parallel scheduling changes, including unbounded parallelism support when explicitly requested and sequential handling for memory-bandwidth-bound crop and convolution paths.
  • Lower-level pixel operations with updated accelerated and fallback paths.

Some of these changes reduce elapsed time. Others reduce allocation pressure or avoid scheduling overhead in paths that already saturate memory bandwidth.

Explicit color management #

Color management changed in V4.

ImageSharp has long been able to preserve embedded ICC metadata. V4 adds decode-time conversion and expands the set of profiles and formats that participate in color conversion. That includes:

  • Colorimetric normalization of JPEG image data during decode.
  • Decode-time ICC conversion for PNG image data.
  • Decode-time ICC conversion for WebP image data.
  • ICC conversion coverage for TIFF, including CIE Lab, CMYK, RGB, and related cases.
  • TIFF/JPEG separated photometric interpretation handling, including default and ICC-driven conversion for JPEG-compressed TIFF files.
  • CICP color metadata support, including PNG cICP chunk read/write support.
  • Support for sparse ICC v4 LUTs.
  • Standards-correct handling around profile connection spaces, canonical sRGB detection, and the D50 PCS illuminant.

Profile handling is now selected on DecoderOptions. A decode can preserve the source profile metadata, remove redundant canonical sRGB profile data, or convert decoded pixels into sRGB before the image reaches later processing steps.

The decode pipeline exposes that choice directly:

using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Formats;

DecoderOptions options = new()
{
    ColorProfileHandling = ColorProfileHandling.Convert
};

using Image image = Image.Load(options, "input-with-icc.jpg");

With ColorProfileHandling.Convert, ImageSharp applies the embedded profile during decode and returns pixels converted to sRGB. With the preserve behavior, ImageSharp keeps the embedded profile metadata attached instead of changing the decoded pixel values for that profile.

This affects format conversion because destination formats do not all support the same color models. WebP, for example, cannot represent CMYK source data directly. Decode-time ICC conversion can convert sources such as CMYK JPEGs to sRGB before saving to formats that store RGB pixels.

V4 also replaces the old ColorSpaceConverter with ColorProfileConverter, which handles working-space and ICC-profile conversion through the same API surface.

For image services, media workflows, and print-sensitive tooling, this reduces the number of cases where callers need to decode, inspect profile metadata, and run a separate conversion step before saving to another format.

Pixel metadata and preflight #

V4 also adds preflight and pixel inspection APIs. ImageInfo.GetPixelMemorySize() gives you a decoded pixel-memory estimate before full decode, which helps when validating uploads, budgeting worker memory, or deciding whether a multi-frame asset should be accepted.

For allocator-level limits, MemoryAllocatorOptions.AccumulativeAllocationLimitMegabytes lets applications cap the total active allocations made through a created MemoryAllocator. The default null value imposes no accumulative total limit. When set, it gives services another way to bound memory use across concurrent image operations, alongside per-allocation limits and preflight checks.

At the same time, the TPixel model and encoded pixel metadata contract carry more data. IPixel exposes GetPixelTypeInfo(), Image exposes PixelType, and PixelTypeInfo can now carry structured information through PixelComponentInfo, PixelColorType, and alpha representation details. That gives ImageSharp internals, codecs, converters, and custom TPixel implementations a contract for questions like whether the source is indexed, luminance-based, RGB, CMYK, YCbCr, or alpha-bearing, how many components it has, and what precision those components carry.

using SixLabors.ImageSharp;
using SixLabors.ImageSharp.PixelFormats;

ImageInfo imageInfo = Image.Identify("input.webp");
PixelTypeInfo pixelType = imageInfo.PixelType;

Console.WriteLine($"{imageInfo.Width}x{imageInfo.Height}");
Console.WriteLine($"Frames: {imageInfo.FrameCount}");
Console.WriteLine($"Bits per pixel: {pixelType.BitsPerPixel}");
Console.WriteLine($"Color type: {pixelType.ColorType}");
Console.WriteLine($"Alpha: {pixelType.AlphaRepresentation}");
Console.WriteLine($"Estimated pixel memory: {imageInfo.GetPixelMemorySize():N0} bytes");

In practice that helps with:

  • Rejecting dangerous uploads before a full decode.
  • Budgeting memory for background workers and queues.
  • Capping active allocator usage in services that process multiple images concurrently.
  • Choosing the right destination format during conversion.
  • Preserving higher-precision or alpha-aware workflows when the target format supports them.

For day-to-day ergonomics, V4 also adds an opt-in UseImageSharp SDK property that pulls in implicit global using directives for the most common ImageSharp namespaces, so new files do not need the same imports repeated everywhere.

Advanced integration points have improved too. IImageFrameVisitor makes it easier for downstream libraries such as ImageSharp.Drawing to work with frame-specific pixel data without losing the generic TPixel contract, while the new buffer subregion helpers expose safer ways to describe and pass bounded memory regions through lower-level code.

These APIs are aimed at callers that need to decide what to do before allocating decoded pixel buffers, or that need to pass frame data into another ImageSharp-based library without losing the concrete pixel type.

Metadata conversion between formats #

V4 adds explicit metadata conversion between formats.

When you load one format and save another, ImageSharp is no longer limited to "decode pixels, then start again from scratch". V4 formalizes metadata bridging with explicit conversion contracts on the metadata types themselves. Image-level metadata converts through FormatConnectingMetadata via ToFormatConnectingMetadata() and FromFormatConnectingMetadata(...), and frame-level metadata uses the matching FormatConnectingFrameMetadata contract.

Those joining types carry the shared semantics that can survive a format boundary: encoded pixel information, lossy-versus-lossless intent, indexed-color behavior such as shared color table mode, and animation metadata such as background color, repeat count, frame duration, blend mode, and disposal mode.

That lets conversions between PNG, GIF, WebP, TIFF, JPEG, and other formats preserve shared characteristics whenever the target format can represent them.

Lower-level metadata handling has also changed. JPEG comments now round-trip through COM marker support, PNG can carry IPTC profiles and CICP color information, XMP profile comparison is normalized through XML semantics, and EXIF encoded strings now follow the byte order declared by the containing TIFF metadata when no byte-order mark is present. Transform operations also update subject-location EXIF metadata where the transformed geometry changes the meaning of the original coordinates.

Format capabilities #

V4 also adds codec-facing capabilities.

The additions include:

  • APNG decoding and encoding.
  • Animated WebP encoding, alongside fuller animated WebP metadata parsing.
  • Progressive JPEG encoding.
  • JPEG COM marker support for image comments.
  • OpenEXR read and write support, including PXR24-compressed OpenEXR decoding.
  • Built-in ICO and CUR decoding.
  • Animation metadata handling across PNG, GIF, and WebP, including repeat counts, frame durations, blend modes, disposal modes, and background behavior.
  • Proper IPTC profile support in PNG.
  • Consistent animation encoder behavior and alpha/transparency handling across supported formats.
  • Metadata conversion APIs between formats.
  • Exposed convolution APIs.
  • Matrix4x4 transform overloads and QuadDistortion support in the projective transform builder.
  • Animation loop control for DrawImage.

These additions sit alongside internal changes to shared metadata, alpha, and animation contracts, so the new formats are not isolated one-off codecs.

For web delivery pipelines, design tooling, conversion jobs, reporting systems, and generated-media workflows, these additions move format handling into ImageSharp instead of application-specific glue code.

APNG, GIF, and WebP describe looping, timing, transparency, blending, and disposal differently. V4 maps those fields through shared animation metadata so conversions can preserve the parts of the source behavior that the destination format can represent.

Robustness across real files #

V4 includes decoder and metadata reliability fixes across GIF, PNG, WebP, TIFF, JPEG, BMP, and TGA.

That includes handling for malformed chunks, truncated files, oversized allocations, frame-count edge cases, palette bugs, overflow conditions, transform correctness, and metadata corner cases.

V4 also adds explicit segment integrity handling during decode, so malformed ancillary data such as ICC profiles, comments, and application extensions can be handled according to decoder policy instead of each format having to make that decision in isolation.

Specific fixes include safer JPEG marker handling, tolerant GIF metadata identification, stricter PNG text and frame-control parsing, TIFF allocation and string-length hardening, WebP chunk parsing normalization, palette and transparency fixes across indexed formats, and defined behavior around odd frame counts or truncated animation data.

Some of that work appears as targeted fixes. Some shows up as explicit exceptions for invalid content. Some appears as decode limits that avoid impossible allocation requests or stop parsing truncated metadata before it corrupts later state.

These fixes are aimed at files from uploads, crawlers, archives, and third-party tools where metadata and frame data are often malformed but the decoder still has to fail cleanly or recover according to policy.

Breaking and operational changes #

V4 includes upgrade considerations.

The baseline change is that ImageSharp V4 targets .NET 8+.

There are also API cleanups and evolutions across areas such as color conversion, transforms, antialiasing, convolution, metadata, and pixel inspection. In most places the direction is simpler and more consistent, but if you maintain lower-level wrappers, custom processors, or integration-heavy code, you should review the release notes carefully before upgrading.

V4 is also the first ImageSharp release to enforce a build-time license key for direct package dependencies.

The licensing behavior is:

  • The license terms themselves are not changing.
  • The new part is build-time enforcement through a sixlabors.lic file.
  • This applies to direct dependencies, not transitive consumers.
  • If you already qualify under the existing terms, your entitlement does not change.

If you are using ImageSharp as a qualifying direct dependency in closed-source software, make sure your licensing setup is in place before upgrading to V4. If you qualify for community licensing, you can apply via licensing.sixlabors.com.

Closing #

It moves ImageSharp to .NET 8+, adds decode-time color conversion, expands animation and metadata handling, adds new codecs and encoder capabilities, improves resize, JPEG, compositing, blending, and memory-buffer paths, and hardens decoders against malformed data across the supported formats.

Thank you, as always, to everyone who has used ImageSharp, reported issues, contributed fixes, and tested previews.

We are excited to see what you build with it.

ImageSharp V4.0.0 is licensed under the Six Labors Split License. This means that it is free to use in both non-commercial and certain commercial applications. However, if you are using it in a commercial application and your organization has annual gross revenue exceeding 1M USD per year, you must purchase a commercial license. Please see the Pricing page for more information.