JPEG/WebP/... part of the executable even if all I do is save a PNG

[MichalStrehovsky]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

ImageSharp version

3.0.1

Other ImageSharp packages and versions

?

Environment (Operating system, version and so on)

Windows 11

.NET Framework version

?

Description

As requested on Twitter: https://twitter.com/James_M_South/status/1673489691956625410

When compiling https://github.com/pjmlp/ppm2png/tree/2b77cfc103f48bbcdce0512f6182153d6d4d8644/csharp with PublishAot, the produced executable is rather large. The reason why it's large can be inspected with Sizoscope. I made this change to the above repo in an attempt to make the size smaller but it didn't help much:

diff --git a/csharp/ImageWriter.cs b/csharp/ImageWriter.cs
index 89af11c..5b4b3eb 100644
--- a/csharp/ImageWriter.cs
+++ b/csharp/ImageWriter.cs
@@ -36,7 +36,7 @@ public static class ImageWriter
     /// <param name="height">The image height in pixels.</param>
     public static void SaveImage(string filename, ReadOnlySpan<byte> buffer, int width, int height)
     {
-        using var image = Image.LoadPixelData<Rgb24>(buffer, width, height);
+        using var image = Image.LoadPixelData<Rgb24>(new Configuration(), buffer, width, height);
         using var stream = new System.IO.FileStream(filename, FileMode.Create);
         var pngEncoder = new SixLabors.ImageSharp.Formats.Png.PngEncoder() {
              ColorType = SixLabors.ImageSharp.Formats.Png.PngColorType.Rgb
diff --git a/csharp/ppm2png.csproj b/csharp/ppm2png.csproj
index c079a6e..cc877f5 100644
--- a/csharp/ppm2png.csproj
+++ b/csharp/ppm2png.csproj
@@ -2,7 +2,7 @@

   <PropertyGroup>
     <OutputType>Exe</OutputType>
-    <TargetFramework>net7.0</TargetFramework>
+    <TargetFramework>net8.0</TargetFramework>
     <ImplicitUsings>enable</ImplicitUsings>
     <Nullable>enable</Nullable>
     <RestoreAdditionalProjectSources>https://www.myget.org/F/sixlabors/api/v3/index.json</RestoreAdditionalProjectSources>

I'm attaching intermediate files that can be opened with Sizoscope:
native.zip but feel free to make your own.

One immediate issue is that this app also includes support for WebP/JPEG/etc. even though I don't need it.

Sizoscope root cause analysis for WebpEncoder..ctor points to Configuration.Default accessed from here:

There might be more issues.

Steps to Reproduce

Clone the repo and build the project. Add switches described in the sizoscope repo if you want to inspect with sizoscope.

Images

No response

[MichalStrehovsky]

Wrong native.zip above. Use this one:

native.zip

[JimBobSquarePants]

Thanks for raising this. This is something I definitely want to get fixed ASAP.

[tocsoft]

don't you just need to set Configuration.Default directly with the required formats to remove the rooting of the additional formats?

[tocsoft]

actually looks like thats not currently possible, but i would have to think adding a setter to Configuration.Default would allow for unrooting our default formats... actually that might not work as the lazy would still be there. I would think we would need some form of contant to switch between modes somehow.... or inversly require all, none AOT, users to manaully make a configuration/initilization call with the default formats to seed the full defaults as required, but that feels horrid.

[tocsoft]

ok looks like we should be able to introduce an MSBuild 'Feature switch' to toggle on the default behaviour of Configuration.Default... i.e. is it seeded with some initial formats or not, with the default being on.

Well based on my quick read of the Customizing Trimming in .NET 5 blog post anyway.

[tocsoft]

I believe it would require adding a new props file to our nuget package that included in the 'transitive build' folder, as i beleive the other one only support direct dependencies.

ImageSharp/src/ImageSharp/ImageSharp.csproj

Line 47 in 2738b3a

<None Include="..\..\SixLabors.ImageSharp.props" Pack="true" PackagePath="build" />

[MichalStrehovsky]

Feature switches are last resort option - they introduce differences in behavior, require explicit opt in, and are a general pain.

From just looking at the above root graph - would a SaveAsPng overload that requires non-null configuration work?

[JimBobSquarePants]

I think looking at using overloads and not falling back to Configuration.Default is the best fix. There are only a few entry points which we can easily sanitize.