With your help, I have already solved the first problem.

libvips is a "pull" system, so you can't "push" tiles into it. Writing intermediate values to temporary objects can help performance in some cases.

It's always best to make a small benchmark that reflects your use case, and then optimise that. Could you make a small, standalone program that shows your whole processing pipeline?

I wrote a code that can demonstrate my real usage process, and the process idea is basically like this. I actually mainly want to avoid wasting a lot of time on calling tiffsave during the final save, and to speed up the efficiency of saving ome.tif.

class::Example
{
public:
	Example() ;
	~Example();
void addBand();
void saveOmeTiff();
private:
std::vector<std::vcector<cv::Mat>> m_allImages;

}

void Example::addBand（int n）
{
	std::vector<vips::VImage> in;
	for (int y = 0; y < r; ++y)
	{
		for (int x = 0; x < c; ++x)
		{
			in.emplace_back(vips::VImage::new_from_memory((m_allImages)[n][y * c + x].data,(m_allImages)[n][y * c + x].cols * (m_allImages)[n][y * c + x].rows * (m_allImages)[n][y * c + x].channels(),(m_allImages)[n][y * c + x].cols, (m_allImages)[n][y * c + x].rows, (m_allImages)[n][y * c + x].channels(),VIPS_FORMAT_UCHAR));
		}
	}
	vips::VImage wholeImg = vips::VImage::arrayjoin(in, vips::VImage::option()->set("across", c)->set("vspacing", 0));
	if (1 == m_time)//At the time of the first band
	{
		m_wholeImg = wholeImg;
	}
	else 
	{
		m_wholeImg = m_wholeImg.bandjoin(wholeImg);
	}
}
void Example::saveOmeTiff()
{
			m_wholeImg = vips::VImage::arrayjoin(m_wholeImg.bandsplit(), vips::VImage::option()->set("across", 1));
			m_wholeImg.tiffsave(("//result.ome.tif",
				vips::VImage::option()->set("compression", "jpeg")->set("tile", true)->set("subifd", true)->set("tile_width", 512)->set("tile_height", 512)->set("pyramid", true)->set("properties", true)->set("bigtiff", false));

}
void main()
{
     Example*test = new Example();
     for(int i =0; i < 5; i++)
{
/*Randomly wait for a period of time to simulate the real waiting time, as it is not possible to obtain complete data for one band at a time. During this period, data for band i will be filled into the test's m_allImages*/
test ->addBand（i）;
}
test->saveOmeTiff();
     return 0;
}

It would probably be best to write your own libvips operation.

You write a function which can generate any tile on demand, then attach that to a VipsImage. There's an example here:

https://github.com/jcupitt/vips-gmic

That lets you call G'MIC (the C++ image processing library) from libvips.

https://gmic.eu/

It would probably be best to write your own libvips operation.

You write a function which can generate any tile on demand, then attach that to a VipsImage. There's an example here:

https://github.com/jcupitt/vips-gmic

That lets you call G'MIC (the C++ image processing library) from libvips.

https://gmic.eu/

If I want to store in different regions, do you have any examples? Divide a large image into several small images for storage, but logically it is still a large image.

Do you mean slicing an image into a regular grid? dzsave can do this.

$ vips dzsave k2.jpg x --depth one --overlap 0
$ ls x_files/0
0_0.jpeg  0_7.jpeg  1_5.jpeg  2_3.jpeg  3_1.jpeg  3_8.jpeg  4_6.jpeg  5_4.jpeg
0_1.jpeg  0_8.jpeg  1_6.jpeg  2_4.jpeg  3_2.jpeg  4_0.jpeg  4_7.jpeg  5_5.jpeg
0_2.jpeg  1_0.jpeg  1_7.jpeg  2_5.jpeg  3_3.jpeg  4_1.jpeg  4_8.jpeg  5_6.jpeg
0_3.jpeg  1_1.jpeg  1_8.jpeg  2_6.jpeg  3_4.jpeg  4_2.jpeg  5_0.jpeg  5_7.jpeg
0_4.jpeg  1_2.jpeg  2_0.jpeg  2_7.jpeg  3_5.jpeg  4_3.jpeg  5_1.jpeg  5_8.jpeg
0_5.jpeg  1_3.jpeg  2_1.jpeg  2_8.jpeg  3_6.jpeg  4_4.jpeg  5_2.jpeg
0_6.jpeg  1_4.jpeg  2_2.jpeg  3_0.jpeg  3_7.jpeg  4_5.jpeg  5_3.jpeg

You can just join them together. Would that work?

In python:

# make a *HUGE* black image
image = pyvips.Image.black(100000, 100000)

# position the first image at the top left
a = pyvips.Image.new_from_file("1.ometif")
image = image.insert(a, 0, 0)

# and the second at the bottom right
b = pyvips.Image.new_from_file("2.ometif")
image = image.insert(b, image.width - b.width, image.height - b.height)

libvips will execute this efficiently -- it'll load a and b on demand, and one tile at a time. It'll never really make the whole image.

I'm probably misunderstanding you!

Sorry, I don't know of a viewer that supports OME-TIFF that way. It'd be quite complicated -- you'd need to read the XML from the two images and try to find which planes they had in common.

You can kind-of do it in nip4:

That's joining two large OME TIFFs top-bottom, but you can join them in any way. The two images view fairly quickly, but viewing the joined image is slow, since it doesn't have the OME pyramid structure.