I'm not sure if this is a bug or expected behavior, so I'm posting here to get your opinion. We're using the .NET bindings and in case it has something to do with that, I'm happy to move it there if more appropriate. But it's more likely a case of "you're using it wrong". I have a complete tiny reproduction case https://github.com/martindisch/AlphaRepro but will explain in more detail here.

We're building an image pipeline to create 8 smaller thumbnails of various sizes from 130px to 2880px. Let's assume our original image is very large so it takes a while to process, for example 10'000px.

We started out by first creating an initial thumbnail that is as large as our largest thumbnail, then using that as the base for all subsequent thumbnail operations. The thinking being that maybe the first thumbnail operation is cached and can be reused for the others, meaning it doesn't have to start from the full 10k image for each, making it faster (not actually true, but we'll get to that). Also note that when saving the image as JPEG (which doesn't have an alpha channel), we're setting the background to 255 to get white instead of black. This will be important later. So far, so simple and misguided 😉

var inputBytes = await File.ReadAllBytesAsync("Rectangles.png");

// This is the original 10000x10000 image
using var image = Image.NewFromBuffer(inputBytes);Add commentMore actions

// Use a more manageable size as a base for the other thumbnails
using var preThumb = image.ThumbnailImage(2880, size: Enums.Size.Down);

foreach (var width in new[] { 2880, 1440, 1000, 720, 480, 320, 260, 130 })
{
    var stopwatch = Stopwatch.StartNew();

    using var thumb = preThumb.ThumbnailImage(width, size: Enums.Size.Down);
    var bytes = thumb.JpegsaveBuffer(background: [255]);
    await File.WriteAllBytesAsync($"out/Rectangles_{width}.jpeg", bytes);

    Console.WriteLine($"Created thumbnail with width {width} pixels in {stopwatch.Elapsed}");
}

As it turns out, our thinking regarding the optimization of the pipeline behavior is wrong—it looks like libvips will start from the big 10k image for each thumbnail, which takes quite a while (well, two seconds on my machine):

$ dotnet run
Created thumbnail with width 2880 pixels in 00:00:03.0623880
Created thumbnail with width 1440 pixels in 00:00:02.2564205
Created thumbnail with width 1000 pixels in 00:00:02.1876179
Created thumbnail with width 720 pixels in 00:00:02.3148522
Created thumbnail with width 480 pixels in 00:00:02.3396053
Created thumbnail with width 320 pixels in 00:00:02.2443918
Created thumbnail with width 260 pixels in 00:00:02.3450774
Created thumbnail with width 130 pixels in 00:00:02.1492182

That's an interesting observation for later, but not the issue here. Besides that, everything works and we get our JPEGs with white background as expected.

Because our original attempt to have libvips start with a smaller thumbnail for each operation didn't work out, we next tried to save the base thumbnail to memory in order to force libvips to evaluate up to that point and guarantee starting from this smaller image each time.

--- a/Program.cs
+++ b/Program.cs
@@ -7,13 +7,22 @@
 using var image = Image.NewFromBuffer(inputBytes);

 // Use a more manageable size as a base for the other thumbnails
+// and force libvips to fully build it in memory
 using var preThumb = image.ThumbnailImage(2880, size: Enums.Size.Down);
+var preThumbBytes = preThumb.RawsaveBuffer();
+using var preThumbImage = Image.NewFromMemory(
+    preThumbBytes,
+    preThumb.Width,
+    preThumb.Height,
+    preThumb.Bands,
+    preThumb.Format
+);

 foreach (var width in new[] { 2880, 1440, 1000, 720, 480, 320, 260, 130 })
 {
     var stopwatch = Stopwatch.StartNew();

-    using var thumb = preThumb.ThumbnailImage(width, size: Enums.Size.Down);
+    using var thumb = preThumbImage.ThumbnailImage(width, size: Enums.Size.Down);
     var bytes = thumb.JpegsaveBuffer(background: [255]);
     await File.WriteAllBytesAsync($"out/Rectangles_{width}.jpeg", bytes);

This does work and has an effect on the timings:

$ dotnet run
Created thumbnail with width 2880 pixels in 00:00:00.0325585
Created thumbnail with width 1440 pixels in 00:00:00.0302317
Created thumbnail with width 1000 pixels in 00:00:00.0289217
Created thumbnail with width 720 pixels in 00:00:00.0313277
Created thumbnail with width 480 pixels in 00:00:00.0216524
Created thumbnail with width 320 pixels in 00:00:00.0193554
Created thumbnail with width 260 pixels in 00:00:00.0193175
Created thumbnail with width 130 pixels in 00:00:00.0168024

However, here comes the issue: the background of the JPEGs is now black as if the transparency information would get lost somewhere along the way.

Some additional observations:

• You can try both versions by checking out commits martindisch/AlphaRepro@399ff7a and martindisch/AlphaRepro@180f398
• There is something going on relating to alpha channels, for example in the last iteration of the code image.HasAlpha() returns true (because the original has it of course), whereas preThumbImage.HasAlpha() says false.
• However: while it does look like the alpha channel getting lost, that's not actually the case. When saving the derived images in a format that supports it—such as PNG—the transparency is actually there in the result despite the intermediate step with raw save. So it only seems to occur when trying to save as JPEG with a background set.
• I did try passing background: [255] to RawsaveBuffer as well, but that's neither what we want (at this point we don't want to be setting backgrounds, as this intermediate image should represent the original as closely as possible, just smaller) nor does it make a difference