How to access on the "cutout" data ?

[Jean-Francois]

Hello Robin,

"There are lots of ways to do it"
Yes, I can confirm that in Python or C# ... it is too many ways to do the same thing.

If I want to perform a "live" processing of the frames (means during the capture itself), yes, it is necessary to have as much as possible.
But the most important is to have a constant frequency.

Here an example what happen if not:

camera_timing_frequency.jpg (388.88 KiB) Viewed 4311 times

The blue arrows show only a very short delay.
The red arrows show the effect on a longer duration.
Note, that the same visual effect can be produced by the change of the telescope rate during the scanning of the sun disc.
Today, the INTI processing software expects a constant frequency of the images. No correction coming from a timestamp.

For a calculation every second frame ... that could be an alternative if it is not possible to have a constant fps during the capture.

I have a look at the garbage collection and the "Server GC" parameters.
Too many ways to do it. It was something promising ... but the System.GC.Server function is not accessible (or present) in the IronPython.
I can have the variable with System.GC.GetConfigurationVariables()
Dictionary[str, object]({'ServerGC' : False, 'ConcurrentGC' : True, 'RetainVM' : False, 'NoAffinitize' : False, ....
But I do not find a way to change the ServerGC = True.
It exists a function to stop the garbage collection ... but it seems that a different function in other library need it and so activate it again.

Beat regards,
Jean-Francois

[admin]

Hi Jean-Francois,

as far as I understand it, the ServerGC has to be set at process start - it can't be altered once the process is running. That's why there are various environment variables listed on that page I linked to... You set the right environment variable before the process starts (in a command window, then run SharpCap.exe from the command window should do it). That way the runtime sees the environment variable as it is initializing and activates the serverGC. You should then see that confirmed by the dictionary of GC data that you can read.

cheers,

Robin

[Jean-Francois]

Hello Robin,

Thanks for the info.

OK, I can set the variable from the CMD window (SET DOTNET_gcServer=1).
Yes, System.GC.GetConfigurationVariables() shows now True.

Without ServerGC (= False): around 250 to 280 images/s. (the first 3 images)
With ServerGC (= True): a boost in the fps ... ~ 350 images/s. But the low frequency are still visible. (the last 3 images)

ServerGC_acticated.jpg (83.31 KiB) Viewed 4278 times

It has an effect ... but not the expected effect

Regards,
Jean-Francois

[admin]

Hi Jean-Francois,

if you cut out the actual processing in your event handler and just record the timepoints, do you get a 'good' trace then (no slowdowns)? Or perhaps longer between slowdowns? If you can find a version of the code that gives the required performance then you can comment in and out chunks of code until you find the bit responsible for the slowdowns in the frame rate. It *might* be that re-using data structures like arrays might help, as that would allocate less data on the heap and cause the GC to kick in less often.

cheers,

Robin

[Jean-Francois]

Hello Robin,

OK, I will test it.

Jean-Francois

[Jean-Francois]

Hello,

Here a summary:

cutout_average_summary.jpg (102.16 KiB) Viewed 4215 times

From the top:
1) calculation with numpy matrix in the framehandler
2) calculation with numpy with separate thread
3) no calculation, but still with "cutout = args.Frame" in the framehandler
4) same as 3), but with ServerGC activated
5) without "cutout = args.Frame" in the framehandler, but with ServerGC activated

The linear scales are the same for all (around 0.18 second from left to right sides).
The 5) has the full fps ... exposure 1 ms => ~ 920 fps for ROI 300x300 of the Jupiter image.

I need to capture an image and to process it. So 2) is better than 1).


Regards,
Jean-Francois

[admin]

Hi Jean-Francois,

they kind of all make sense apart from the difference between 4) and 5). The line

Code: Select all

cutout = args.Frame

really doesn't do anything significant - it should just copy an 8 byte address of one variable into another. If you do anything with the 'cutout' frame variable that would be something else, but the code above doesn't copy the frame, just makes it so that the cutout variable now points to the same frame that is in args.Frame.

Now, obviously this is python, so copying an 8 byte address isn't one assembly language instruction - there's lots of 'interpreter' stuff to do, but even so, it should be pretty quick...

Not sure what else would help at this stage - probably putting the code into a C# DLL, but then you cannot reference the SharpCap types, so everything would have to be dynamic and that's messy too...

cheers,

Robin