I see…
I have played around a little and wrote a small test program to test different formats. In order to be able to benchmark all formats I have decided to use 8bpp, but adapting it to different bit-depths should be fairly easy. For simplicity I have used our new .Net wrapper (see here). The figures are as follows:
| Format | Time to save 1 MPixel mono | Time to save 1 MPixel RGB |
|---|---|---|
| BMP | 9.46 ms | 27.03 ms |
| MIO | 10.89 ms | 25.75 ms |
| JPG | 111.08 ms | 155.86 ms |
| TIF | 82.74 ms | 109.63 ms |
| PNG | 136.19 ms | 275.99 ms |
| J2K | 269.17 ms | 1368.79 ms |
Now, there is indeed a way to speed things up for all formats except BMP and MIO. To understand how one has to know that BMP and MIO are being saved directly by the CVCImg.dll, while all the other formats are catered to by the CVCFile.dll. If you call WriteImageFile in the CVCImg.dll, the function looks at the extension of the target file name and if that extension points to anything else but BMP or MIO, it’ll dynamically load the CVCFile.dll, pass the job over to that DLL and unload it once the file has been saved. This recurring saving and unloading of files can become a bit of a performance hog, so one workaround for you might be to make sure that the CVCFile.dll is not being unloaded between images. To do so, you simply need to call LoadLibrary and not call FreeLibrary before you have saved all the images.
To access those two functions in C# you will of course need to import them first:
[DllImport("kernel32.dll")]
public static extern IntPtr LoadLibrary(string fileName);
[DllImport("kernel32.dll")]
public static extern bool FreeLibrary(IntPtr hModule);
Then you can
...
var module = LoadLibrary("CVCFile.dll");
...
// save your images here
...
FreeLibrary(module)
When benchmarking with that fix in place the numbers are as follows (at leas on my machine):
| Format | Time to save 1 MPixel mono | Time to save 1 MPixel RGB |
|---|---|---|
| BMP | 8.70 ms | 28.25 ms |
| MIO | 8.26 ms | 27.36 ms |
| JPG | 26.23 ms | 74.50 ms |
| TIF | 2.69 ms | 26.76 ms |
| PNG | 59.41 ms | 193.48 ms |
| J2K | 182.76 ms | 1300.56 ms |
The differences for BMP and MIO compared to the previous measurement are probably just fluctuations that would be averaged out when performing more measurements. The increase in speed for the CVCFile.dll formats, however, is notable - at least for all formats except JPEG2000 which generally is a very computationally costly format. Speed may of course also vary with images content for the compressing formats (i.e. all except BMP and MIO), but judging from these numbers your chances are good to reach the required 12 fps with TIFF.
If the LoadLibrary/FreeLibrary workaround is not enough, however, I might be out of options here. Streaming formats can - with the help of hardware accelerated codecs - often reach significantly higher throughput, but these capabilities cannot be leveraged by WriteImageFile - one would need to code the compression in CUDA or OpenCL to reach similar speed. Plus streaming formats are usually limited to 8 bits per pixel. In summary: If the workaround is not fast enough for you you might need hardware acceleration.
BTW: You will only see these differences if you are not using the Image and/or Display control in your application. Both controls are linked against the CVCFile.dll and will keep the DLL open as long as there are instances of these controls active in your application.