Page 2 of 2
Re: Custom frame transform?
Posted: Tue Sep 25, 2018 11:22 am
by furrysocks2
Got something working now from Python->C++... it's not fast, but yet to work out why. [Edit - it was a debug build - release is somewhat faster]
Code: Select all
dll=ctypes.CDLL(dllfile)
def handler( sender, eventArgs):
frame = eventArgs.Frame
info = frame.Info
bufsize = int(frame.BufferSize)
lease = frame.GetBufferLease()
frameData_addr = lease.Buffer.ToInt64()
frameData_ptr = ctypes.cast(frameData_addr, ctypes.POINTER(ctypes.c_ubyte))
dll.do_foo(frameData_ptr, info.Width, info.Height, bufsize);
lease.Dispose()
Re: Custom frame transform?
Posted: Tue Sep 25, 2018 8:34 pm
by furrysocks2
I added a button to the toolbar to open a dialog and allow me to vary the parameters to the C++ routine. Currently only MONO8, but I'll see about MONO16 and perhaps RGB.
The approach you suggested certainly works. I don't know to what extent ADPB suits astro images, but I've something to play with now.
Thanks for your help!
- sharpcap adpb.gif (118.15 KiB) Viewed 3173 times
Re: Custom frame transform?
Posted: Tue Sep 25, 2018 9:14 pm
by admin
Awesome! That's really cool.
How much processing time does it take per frame?
cheers,
Robin
Re: Custom frame transform?
Posted: Tue Sep 25, 2018 9:54 pm
by furrysocks2
Thanks!
I've instrumented the C++ and return the execution time to Python - approximately 160ms per frame (1280x960 MONO8).
Re: Custom frame transform?
Posted: Tue Sep 25, 2018 10:05 pm
by furrysocks2
admin wrote: ↑Sun Sep 23, 2018 7:53 pm
events on the Camera class (FrameCaptured, BeforeFrameDisplay)
I'm assuming dark subtraction and other things happen between these two events?
Re: Custom frame transform?
Posted: Wed Sep 26, 2018 5:37 pm
by admin
Hi,
yes, the FrameCaptured event is pretty much the first thing that happens after the data comes off the camera - nothing will have touched the image data at this point.
BeforeFrameDisplay is the last thing before showing on screen - at this point dark/flat processing, frame transforms have happened. The frame is still at it's original bit depth and may not have been debayered by this point (some transforms debayer the frame earlier than this). The frame has also already been written to file if capturing at this point.
cheers,
Robin