Lead 17 crashes when constructed image is too large

The attached project demonstrates the problem. How can I change the code to support constructed images of arbitrary size?

There is no attachment with this post. If you want to attach file/images, put them in a ZIP or RAR file, and don't use the Preview option when attaching.
If you don't want to put your files on our forums, you can send them to support@leadtools.com and mention this post in your email.
Also, please do not include any of our LEADTOOLS DLLs or headers in your attachment.

.

I tried your project and our toolkit did not crash. The pages kept getting added to the RasterImage object, with each page increasing the memory use by a little less than 15 Megabytes, which is the size of each bitmap (width * height * 4 bytes = 1700*2200*4).

After a number of loops that depends on the amount of free memory used by the bitmaps, the ConvertFromImage function triggered an exception.

This is normal because you will always have a limit on the number of bitmaps you can hold in memory at the same time.

Is there a reason why you want hundreds of bitmaps held in the same RasteImage object simultaneously? Regardless of what your application does with multiple pages, there are usually ways to handle these pages without keeping them all in memory together. If you give me more details about your requirements, I might be able to suggest alternative techniques.

I'm building a RasterImage object from each page sent to the virtual printer during a print job. I take each page event, build a bitmap, add it to the RasterImage, and dispose of the bitmap.

Some of those print jobs are hundreds of pages, and some users expect to work with over 1000 pages at a time. At the end of a print job, the RasterImage object is saved to disk as a multi-page TIF and passed along to another program.

The requirements for the resulting file are to contain every page sent (none missing due to out-of-memory exceptions), and to be a single multi-page 1bpp G4 TIF containing all the individual pages. That is, a 1000 page printed document must generate a 1000 page TIF, not 1000 single-page TIFs. I'm open to any suggestion that would satisfy those requirements.

It will be much faster and less error prone if you do it as follows:
1. When the first page in the print job arrives, create a new TIFF file and save the first page in it as TIFF CIITT Group4 then free the RasterImage object immediately.
2. When other pages in the same print job arrive, call RasterCodecs.Save with the same file name, but using a page mode of CodecsSavePageMode.Append, then free the RasterImage object again.

This means at any one point in time, you will only have one page in memory, but all pages will be saved to disk into one big file.
Our CCITT Group 4 compressor is very fast and it should be able to append the pages while the print job is still being processed.