low FPS with my C Code

royed

Hello,
I have a ZWO ASI 183MM camera, which when I use ASICap gives me an FPS >500, but when I try to call the ASIGetVideoData over a loop, my FPS drops to 20. I have written the code in C, and the specific part that calls the functions over the loop is shown below. Please help me out with this:

                long lBuffSize= height*width;
		unsigned char *pBuffer= (unsigned char *) malloc(lBuffSize) ;
		double *imBuffer= (double *) malloc(lBuffSize*8) ;
                ASIStartVideoCapture(cameranumber);
		
		Timer();
		int q=0 ;

		while(1)
		{
			
			exposurestatus=ASIGetVideoData(cameranumber, pBuffer, lBuffSize, exposure*2+500);
			value=0;
			if(exposurestatus==0)
			{
				ConvertArrayType (pBuffer, VAL_UNSIGNED_CHAR, imBuffer, VAL_DOUBLE, lBuffSize);
				MaxMin1D (imBuffer, height*width, &maxvalue , &maxvalloc ,&minvalue , &minvalloc);
				
				for (int i=29; i>=0; i--)
				{
					colors[i].dataValue.valDouble = (double)(value);
					value = value + ((maxvalue - minvalue) / 29.0);
				}
				
				PlotIntensity (panelHandle_2, VIDEOPANEL_GRAPH, imBuffer, width, height, VAL_DOUBLE, colors, 0xffffff, 30, 0, 0);
				
			}
			else if(exposurestatus!=0)
			{
				char str[100];
				sprintf(str,"Error code %d",exposurestatus);
				MessagePopup ("Error", str);
				break;
			}
			
			
			ProcessSystemEvents ();
			GetCtrlVal (panelHandle_2, VIDEOPANEL_TOGGLEBUTTON, &val);
			if(val==1)
			{
				break;
			}
			q++;
			
		}

		ASIStopVideoCapture(cameranumber);

		printf("%d %lf", q,Timer());

		ASICloseCamera(cameranumber);

w7ay

What did you set as ROI size and the ROI bin (ASISetROIFormat)? Check also the ASI_BANDWIDTHOVERLOAD control parameter, bit depth (ASI_IMG_TYPE) and exposure time. All those can limit your frame rate.

20 FPS sounds about right for an ROI that fills that camera's frame.

It has been more than 5 years since I used the ASI Camera SDK (MacOS X), but those are some parameters that comes to mind.

Chen

royed

w7ay Hello Chen, for the maximum resolution, I have about 1.2 FPS, I get approximately 20FPS for the smallest resolution, while the ASicap gives >500FPS.

w7ay

royed I have about 1.2 FPS, I get approximately 20FPS for the smallest resolution

Yeah, that doesn't sound right.

It can't be your USB hardware and drivers (at least I don't think so), since I presume ASIcap is running correctly on the same machine that you are coding on.

Perhaps you can try simply time a fixed number, say 100 frame captures (ASIGetVideoData) without doing anything with the data that is returned by the call. That would get ConvertArrayType and plots and GUI out of the way, to make sure one of these is not the culprit. Timing a fixed number of frames would also avoid calling ProcessSystemEvents and GetCtrlVal for your stop button too.

All else fails, perhaps you can get ZWO (I find it best to email support directly; there is too much noise on the forum) to send you a sample code snippet.

Chen

P.S. I usually run all the GUI on a different thread from actual imaging stuff. Just make sure the API calls are thread safe, otherwise you would need to install some locks.

royed

w7ay Thank You for the reply. I have tried testing the ASIGetVideoData function without any other GUI callbacks or any other functions, and still, the FPS is low. Thank You for the suggestion with the multithreading for the GUI. That would definitely make some issues better.

royed

w7ay Hello Chen,
I wanted to ask you about the Multiple thread for GUI, Although I get the data, running the second thread still slows the acquisition speed as the second thread shares the same variable, is there something that you would suggest to counter this?

w7ay

royed Multiple thread for GUI

The simplest way is to make the GUI Thread only update every 10 acquired images. Or run an NSTimer in the GUI thread so that the timer only wakes up every 100 milliseconds for example.

Remember that the NSTimer needs its own Run Loop -- many people miss that one :-). By default Cocoa sets up a default run loop in the Main Thread. But you need to create your own if you want to use something like NSTimer in your own thread. NSTimer is simply an event in the run loop.

Thread Safety can be a tricky thing, since you need to lock the shared data, and that may keep your imaging thread from running. An easy way to share data is to use the Producer-Consumer model (one thread only writes and the other thread only reads), but even there, you will need to have multiple buffers to minimize the time both treads try to acquire the same shared data. You can assign a separate lock to each buffer, for example.

By the way, can use the -tryLock method in NSLock, instead of the -lock method to avoid being deadlocked.

Chen

royed

w7ay Thank You for this suggestion, I shall try to build upon both these ideas! Thank You so much!

royed

w7ay Hello Chen,
I have the last question for you, apologies for bothering you so much. What do you suggest for saving the data that we receive? As for a single measurement, I might need to save more than 500 frames. What do you suggest in such a case?

alastroct

The specs for the 183mm on the ZWO website give a max FPS of 19 at highest resolution (5496×3672) .

https://astronomy-imaging-camera.com/product/asi183mm-pro-mono

Seems to me that your API call could be functioning properly and ASICap is reporting an erroneous FPS./

royed

alastroct The ASICap at the full resolution does give an approximate 19FPS, while my initial code was slowing down, but I have been able to counter that, the issue was due to a SystemEvents call that I was making to break the data acquisition loop by a GUI call. After changing the parameters for that call, I was able to get the Highest FPS Possible with the camera.

w7ay

royed What do you suggest for saving the data that we receive?

I am not sure what you mean by that. You save it to where you need to use it, of course. Just don't write to a rotating hard drive. Get a fast SSD.

As for a single measurement, I might need to save more than 500 frames. What do you suggest in such a case?

I would suggest choosing the smallest ROI during capture time. Are you capturing multiple short frames for lucky imaging? If so, you have no choice but to save all frames unless you have some fast rejection algorithm to toss the bad frames.

If it is a color camera, you could deBayer on the fly into a smaller color image. But that won't work if you also plan to drizzle the Bayer array.

With a small ROI, you can probably load the Mac up with more RAM and stage all the data into RAM first. mallocs take very little time :-). I have the liberty for example to do that with my MacPro, but unfortunately I am memory limited with my M1 Mac Mini and M1 MacBook Pro.

If the ROI only takes up a megabyte, you can stage a thousand frames into RAM without worry.

If you are trying to eventually stack many frames, you don't really need that deep an image, either. 8 bits might suffice, since the variance of the quantization noise would half each time you double the number of frames -- i.e., you gain 1 bit of dynamic range for every 4x number of frames (signal jumps by 6.02 dB per doubling of frames, while quantization noise jumps by 3.01 dB; thus the signal to quantization noise improves by 3 dB (3.16x) for each doubling of frames).

In this context, "signal" incorporates both desired starlight and undesired sky background noise. The rule of thumb is that once the sky background is 10 dB higher than the quantization noise, you no longer get significant improvement of SNR by using higher bit resolution -- you are limited by SNR of starlight vs sky background noise. (This is the same set of considerations that you would use when considering A/D converter resolutions for a DSP radio, where you have the radio signal, cosmic background noise and A/D quantization noise).

In short, I don't think you will have any problem staging the frames to RAM first, unless your computer is really starved for RAM.

Chen

royed

w7ay That seems like a viable option! Thank You!