John Cupitt

Argh, the old docbook markup is no longer supported in current gtkdoc. I've redone them in ascii art, thanks!

There are a few others that need fixing too: ``` ~/GIT/libvips/libvips (master) $ grep -l tgroup */*.c arithmetic/add.c arithmetic/arithmetic.c arithmetic/divide.c arithmetic/multiply.c arithmetic/subtract.c arithmetic/sum.c deprecated/im_lab_morph.c ```

Hi again, sure, let's tag this as an enhancement. Do you have a sample image we could use for testing?

Hi @andreas-kupries, You're right, that's some crusty old code left over from before `atan2` and `hypot` became a thing. We still work on platforms without these functions, so we'd need...

Oh, interesting @bdal-jsinge! TIFF pyramid generation runs in two main phases: it renders every level in parallel to a set of separate TIFF files, then in a second pass gathers...

I tried on ubuntu: ``` $ vips tiffsave C2023000589S1-0-1_743eee76-f53b-aca2-4da5-fa97a44d9933_125232.svs x.tif --tile --pyramid --compression jpeg --bigtiff --vips-progress vips temp-5: 211213 x 87581 pixels, 32 threads, 128 x 128 tiles, 640 lines...

libvips is opening the output TIFF in `w8` mode, ie. bigtiff write. For some reason the conan libtiff build does not seem to support this (I think?) hence the failure....

How strange! Could you try: ``` vips.exe black x.tif[bigtiff] 100000 100000 --vips-progress ```

I fired up a windows VM and tried with the `vips.exe` we distribute: ``` F:\vips-dev-8.15\bin>vips.exe black x.tif[bigtiff] 100000 100000 --vips-progress vips.exe temp-1: 100000 x 100000 pixels, 8 threads, 100000 x...

Ooof, so sorry, my disk was filling up and that was stopping the write! I suppose the error codes are not being mapped into strings correctly -- it should be...