Memory consumption problem in Aspose.Imaging

Aspose.Imaging Product Family
1

Hello there,

I am running into an annoying memory problem using Aspose.Imaging. In particular, I am trying to convert the first page of a multi-page tiff into a jpg image. Profiling the code I have seen that a lot of RAM (some Gbs) is used by a Aspose.Imaging.Color[] structure that seems to be the color palette. The problem is proportional to the input and output image size and it does not depend on a specific tiff image.

Here the code:
using (Aspose.Imaging.FileFormats.Tiff.TiffImage image = (Aspose.Imaging.FileFormats.Tiff.TiffImage)Aspose.Imaging.Image.Load(stream))
{
Aspose.Imaging.FileFormats.Tiff.TiffFrame frame = image.Frames[0];
Aspose.Imaging.ImageOptions.JpegOptions jpegOptions = new Aspose.Imaging.ImageOptions.JpegOptions();
jpegOptions.Quality = this.DocumentPreviewConfiguration.ImageQuality;
using (MemoryStream imageStream = new MemoryStream())
{
frame.Save(imageStream, jpegOptions);
}
}

Thanks in advance,
Diego

2

Hi Diego,


Thank you for contacting Aspose support.

We are aware of the fact that Aspose.Imaging.Color[] structure uses too much memory during the copy operations. Reason being, the Color struct requires more memory for the data storage since the API requires to store additional system information along with 4 bytes data. In order to overcome this situation we have planned to switch the internal structure to use byte[] instead Color[] because doing so will increase the overall performance.

Good news is that we have partially implemented the above discussed approach for BMP file format. This partial implementation of Raw Data Processing instead of Colors will be published with the upcoming release of Aspose.Imaging for .NET 2.4.0, that is due in a couple of days. We hope to complete this task for other file formats (including TIFF) with the release of Aspose.Imaging for .NET 2.5.0, that is scheduled for the first quarter of June 2014.

We need to log a ticket against your inquiry so that you could be notified automatically once a fix is available for public use. Moreover, we require the samples from your end that are exhibiting the major memory spikes when processed with your provided code snippet. These samples will help us during the testing of the fix version against your particular scenario.