John Cupitt

There's a new libheif due in a couple of days which should improve this. I think I'd try again with that.

I wasn't sure we'd arrived at consensus on this. Do you think that branch is the best solution for now? The huge black areas are very unfortunate.

Hi @John-P, openslide images are all RGBA, so the TIFF will be saved as RGB plus an unpremultiplied alpha (non-assoc). You can flatten out the openslide alpha before save, would...

Ah hang on, perhaps the libtiff webp writer doesn't know about alpha? That might explain it.

I tried: ``` $ vips copy PNG_transparency_demonstration.png x.tif[compression=webp,tile,tile-width=128,tile-height=128] $ tiffinfo x.tif TIFF Directory at offset 0x80248 (13978) Image Width: 800 Image Length: 600 Tile Width: 128 Tile Length: 128 Resolution:...

Hi @joshuamsager, That's bad, I'll have a think. (From your stack trace it looks like you're not using sequential mode -- enabling it might fix your problem, though of course...

> Our images are always loaded in memory prior to calling libvips which is why we never really considered enabling sequential mode. But they are loaded in memory as bit...

I made you a tiny benchmark: ```python #!/usr/bin/python3 import sys import time import pyvips pyvips.cache_set_max_mem(0) pyvips.cache_set_max(0) with open(sys.argv[1], "rb") as f: data = f.read() iterations = 10 print("testing random mode...

Ah that's a shame. `vipsthumbnail` handles this by doing `copy_memory` after the shrink, and then only rotating the thumbnail (not the large input image). That way you can run 90%...

Could this be a fork() issue? This is something we've struggled with in some web applications. libvips will probably crash if you fork() after processing any pixels, or during vips_init()....