Creating a Zoomify tile set, the NUMTILES property in ImageProperties.xml may report a slightly less value.

Setup

Running vips 8.15.1 on Windows 7 x64 from the command line, but a test with vips 8.17.2 on Windows 10 also shows this bug. CPU is a Xeon quad core.

Use a large image like this landscape (15000x5052 px):
Image: https://i.pinimg.com/originals/a7/e0/30/a7e030dd44130f6edbddb5ae725d782c.jpg

Create a custom Zoomify layout with a rather sparse tile set:
vips dzsave landscape.jpg landscapezf --layout zoomify --background 0,0,0 --skip-blanks 100 --tile-size 256 --overlap 2

The generated tile set always has 1553 tiles so ImageProperties.xml should read

<IMAGE_PROPERTIES WIDTH="15000" HEIGHT="5052" NUMTILES="1553" NUMIMAGES="1" VERSION="1.8" TILESIZE="256" />

however it might randomly generate slightly less NUMTILES like

<IMAGE_PROPERTIES WIDTH="15000" HEIGHT="5052" NUMTILES="1552" NUMIMAGES="1" VERSION="1.8" TILESIZE="256" />

The source uses tile_count to track the NUMTILES:

	/* And count tiles so far in this level.
	 */
	n += y * level->tiles_across + x;

	vips_snprintf(subdir, VIPS_PATH_MAX, "TileGroup%d", n / 256);
	vips_snprintf(name, VIPS_PATH_MAX,
		"%d-%d-%d%s", level->n, x, y, dz->file_suffix);

	/* Used at the end in ImageProperties.xml
	 */
	dz->tile_count += 1;

and writes the output with
vips_dbuf_writef(&dbuf, "<IMAGE_PROPERTIES "
"WIDTH="%d" HEIGHT="%d" NUMTILES="%d" "
"NUMIMAGES="1" VERSION="1.8" "
"TILESIZE="%d" />\n",
dz->level->width,
dz->level->height,
dz->tile_count,
dz->tile_size);

That seems quite straightforward, so perhaps there is some race condition in the multicore processing that causes this glitch.